@redsift/icons 11.3.0-muiv5 → 11.3.1-alpha.0

package/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contribute
 
-## Develop
+## Setup
 
 Make sure you have the following requirements installed: [node](https://nodejs.org/) (v16+) and [yarn](https://yarnpkg.com/en/) (v1.22.0+)
 
@@ -26,7 +26,7 @@ You can then run the storybook and browse to [http://localhost:9000](http://loca
 yarn start:storybook
 ```
 
-### Architecture
+## Architecture
 
 The Design System is following a monorepo architecture, providing multiple packages based on different use cases.
 
@@ -68,8 +68,6 @@ The Design System is following a monorepo architecture, providing multiple packa
 
 Please make sure to work inside the correct package when making contribution.
 
-### Shared code
-
 If you need something inside more than one package, do not duplicate the code. Place it inside one package, export it from this package and import it inside the others.
 
 For instance, `@redsift/dashboard` and `@redsift/charts` both have a `PieChart` component that both share the `PieChartVariant` type interface. `PieChartVariant` has been implemented inside `@redsift/charts` and is imported inside `@redsift/dashboard`.
@@ -102,9 +100,11 @@ When dependencies are required, we try not to import them entirely to optimise t
 import * as d3 from 'd3';
 
 // do
-import { sum, scaleOrdinal } from 'd3';
+import { sum as d3sum, scaleOrdinal as d3scaleOrdinal, ScaleOrdinal as d3ScaleOrdinal } from 'd3';
 ```
 
+## Component
+
 ### Scaffolding
 
 Each component should be in its own folder. If a subcomponent can be used as a standalone component, it should be in its own folder too. For instance, `CheckboxGroup` uses `Checkbox` but `Checkbox` can be used alone. In this case, `CheckboxGroup` and `Checkbox` both have their own folder. For `PieChart` and `PieChartSlice`, a `PieChartSlice` can not be used alone. It only exists inside a `PieChart` component. Therefore, both components are inside the same folder.
@@ -191,40 +191,6 @@ size?: PieChartSize;
 
 To know how to define your API, to name and document your props, take a look at the existing components.
 
-## Tests
-
-We use [jest](https://jestjs.io/) for unit tests and [react-testing-library](https://testing-library.com/docs/react-testing-library/intro) for rendering and writing assertions. We also use [Storyshots](https://storybook.js.org/addons/@storybook/addon-storyshots) to automatically take a code snapshot of every story.
-
-Please make sure you include tests with your pull requests. Our CI will run the tests on each PR. A minimum of 90% code coverage is required for statements, branches, functions and lines of every package. However, in practice, we try to reach a 100% code coverage.
-
-We split the tests into 2 groups.
-
-_Visual tests_
-
-- A Storybook story should be written for each visual state that a component can be in (based on props).
-
-_Unit tests_
-
-- (Props) Anything that should be changed by a prop should be tested via react-testing-library.
-- (Events) Anything that should trigger an event should be tested via react-testing-library.
-
-You can run the tests with:
-
-```bash
-yarn test
-```
-
-Or for a specific package with:
-
-```bash
-yarn test:charts
-yarn test:design-system
-yarn test:dashboard
-yarn test:table
-```
-
-Do not forget to update the snapshots with the `-u` option when you modify or create stories. However, you should **always** check the generated snapshots to see if they are correct. Do **not** blindly update the snapshots.
-
 ## Linting
 
 The code is linted with [eslint](https://eslint.org/). You can run the linter with:
@@ -242,7 +208,7 @@ yarn lint:design-system
 yarn lint:table
 ```
 
-## TypeScript
+## Typing
 
 The code is written in [TypeScript](https://www.typescriptlang.org/). The type checker will usually run in your editor, but also runs when you run:
 
@@ -329,6 +295,40 @@ Before implementing a component, try to see if there is a [pattern](https://www.
 
 However, before using any ARIA, [read this disclaimer carefully](https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/).
 
+## Tests
+
+We use [jest](https://jestjs.io/) for unit tests and [react-testing-library](https://testing-library.com/docs/react-testing-library/intro) for rendering and writing assertions. We also use [Storyshots](https://storybook.js.org/addons/@storybook/addon-storyshots) to automatically take a code snapshot of every story.
+
+Please make sure you include tests with your pull requests. Our CI will run the tests on each PR. A minimum of 90% code coverage is required for statements, branches, functions and lines of every package. However, in practice, we try to reach a 100% code coverage.
+
+We split the tests into 2 groups.
+
+_Visual tests_
+
+- A Storybook story should be written for each visual state that a component can be in (based on props).
+
+_Unit tests_
+
+- (Props) Anything that should be changed by a prop should be tested via react-testing-library.
+- (Events) Anything that should trigger an event should be tested via react-testing-library.
+
+You can run the tests with:
+
+```bash
+yarn test
+```
+
+Or for a specific package with:
+
+```bash
+yarn test:charts
+yarn test:design-system
+yarn test:dashboard
+yarn test:table
+```
+
+Do not forget to update the snapshots with the `-u` option when you modify or create stories. However, you should **always** check the generated snapshots to see if they are correct. Do **not** blindly update the snapshots.
+
 ## Storybook
 
 We use [Storybook](https://storybooks.js.org) for local development. Run the following command to start it:
@@ -413,3 +413,27 @@ yarn build:icons
 yarn build:legacy
 yarn build:table
 ```
+
+## Publishing a release
+
+### Stable release
+
+1. Make sure you're on the release branch (ex: `release/vX.Y.Z`) and a PR is opened on Github
+2. Login to NPM with an authorized account: `npm login`
+3. Make sure your packages are up to date: `yarn`
+4. Make sure the CI entirely passed on Github
+5. (Optional) Make sure the build doesn't crash locally: `yarn build:design-system`
+6. Publish the packages to NPM: `yarn release vX.Y.Z`
+
+### Alpha release
+
+If you need to test your contribution in a product before releasing -and you're not using `yarn link`, you can create an alpha release using the following process:
+
+1. Create an alpha release branch (ex: `release/vX.Y.Z-alpha.N`) based on `release/vX.Y.Z`
+2. Push it to remote (`git push origin release/vX.Y.Z-alpha.N`)
+3. Login to NPM with an authorized account: `npm login`
+4. Make sure your packages are up to date: `yarn`
+5. (Optional) Make sure the build doesn't crash: `yarn build:design-system`
+6. Publish the packages to NPM: `yarn release --dist-tag alpha vX.Y.Z-alpha.N`
+
+After that if you need to make modification to your contribution, go back to `release/vX.Y.Z` and make the necessary modifications. Then remove the alpha release branch, and redo the process from step 1, incrementing `N` by 1.

package/package.json

@@ -26,7 +26,7 @@
     "prepublishOnly": "yarn build"
   },
   "types": "index.d.ts",
-  "version": "11.3.0-muiv5",
+  "version": "11.3.1-alpha.0",
   "dependencies": {
     "@mdi/js": "^7.1.96"
   },
@@ -72,5 +72,5 @@
     "react": ">=17",
     "react-dom": ">=17"
   },
-  "gitHead": "006d58b3a764a542ac05cbb32e12e881503cb1c2"
+  "gitHead": "5d8df901d54b5e7f4069f7500a976e190742014a"
 }