# Netbase Design System
This is the home of the front-end component library we built to support our product at Netbase.

Live demo and detail documentations for each components please see [ui.netbase.com](https://ui.netbase.com).
## Usage 👨🏻‍💻
This repository contains a list of node packages (located under `packges/<pkg_name>`) each hosts different parts of our UI components which can be installed/published individually depending on your usage.

Currently, all the packages is scoped under `@netbase-ui` namespace, hence you can install the package you need by:

npm install --save @netbase-ui/<pkg_name>

# or

yarn add @netbase-ui/<pkg_name>

Detailed instructions can be found in the README.md of each package folder and additional documentation can be found in [ui.netbase.com](https://ui.netbase.com).

## How to contribute 👩🏻‍💻
### Prerequisite
- Make sure you're running **Node v14.18.1**.
- Install [lerna](https://github.com/lerna/lerna) as a global package:

npm i -g lerna

### Starting local environment
First, install all the dependencies by running:

npm ci

Second, use [lerna bootstrap](https://github.com/lerna/lerna/tree/main/commands/bootstrap) to install all of the dependencies and links any cross-dependencies for the packages:

lerna bootstrap --ci

And you can test your newly added components in stroybook:

npm run storybook

Finally, you can document your components in the styleguidist. To start the styleguidist dev environmnent:

npm run styleguide

### Adding new packages

Using [leran create](https://github.com/lerna/lerna/tree/master/commands/create) to add new packages:

lerna create @netbase-ui/<your_package_name> --registry="https://maven.netbase.com/repository/npm-releases/" --yes

Using [lerna add](https://github.com/lerna/lerna/tree/master/commands/add) to manage package dependencies:

# We are using React, let's add it as dev dependency for local testing
lerna add react@17.0.2 --dev --scope=@netbase-ui/<your_package_name>

# And as a peer dependency using major 16 version for consuming applications
lerna add react@17.x --peer --scope=@netbase-ui/<your_package_name>

# Adding other dependencies that you might need
lerna add @netbase-ui/theme --scope=@netbase-ui/<your_package_name>
lerna add styled-components --scope=@netbase-ui/<your_package_name>
lerna add styled-system --scope=@netbase-ui/<your_package_name>

Configure your `package.json`, make sure it contains the following fields:

{
  "src": "lib/<your_package_name>.js", // entrypoint for styleguidist, see more details in below note
  "main": "dist/<your_package_name>.cjs.js",
  "module": "dist/<your_package_name>.esm.js",
  "scripts": {
    "build": "netbase-ui-builder",
  },
  "devDependencies": {
    "@netbase-ui/builder": <the_latest_version>,
  },
}

* Note: For the scenario like `<package_A>` depends on `<package_B>`(eg. `@netbase-ui/wordCloud` depends on `@netbase-ui/theme`).
Since we want Styleguidist resolve to the original file of `<package_B>`(instead of the built files) in order to have the code change be seen at hot reload.
We set `src` as prioritized field in Styleguidist webpack config.

If you've added any thirdparty dependencies, please make sure to add them into [external list in builder.js](https://git.netbase.com/projects/WEB/repos/netbase-design-system/browse/packages/builder/lib/builder.js#22)

### Workflows
Currently, there're two kinds of branches in the repo:
- `main` : Used to publish official versions.
- `feature/*` : Used to publish testing versions.

Note: feature branch name is required to start with `feature/*` otherwise the build/publish process will fail.

Here is the recommended workflow:
1. Create your own feature branch from `main` branch.
2. Structure your commit message by following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) then push to remote.
3. When you're done developing features, open a pull request to `main` and jenkins will then pick up the changes from your branch and start building & publishing testing version of those packages under version: `<version>-PR-<pr_nubmer>-<test_version>`.
4. Before merging back to `main`, make sure you:
- DO NOT rebase onto master (this might result in older package versions in the latest commits which will break the publish process)
- Instead, you should merge `main` into `feature/*` and resolve conflicts by choosing the newer versions in `package.json` and all the changes you want.
5. Merging PR back to `main` on github.