After that's set up in your shell (just follow the instructions at the end of the installation script) you can run `nix-shell` to get a development environment with everything you need.
If you find that `direnv` loads too slow, [there are faster loading strategies than the default in their wiki](https://github.com/direnv/direnv/wiki/Nix).
You can run the Puppeteer tests for only one component by passing the name of the component to the test script, for example: `./script/puppeteer-tests-no-percy.sh Button`
If you'd like to test your widget in the monolith before publishing, run `script/test-elm-package.py ../path_to_this_repo` from the monolith's directory.
## Deploying
Once your PR is merged, you can publish `master` as a new version:
Run the following to bump && publish the version in `elm.json`:
Suppose you just released version `5.0.1`, a small styling fix in the checkbox widget, for a story you're working on. If the project you're working in currently pulls in `noredink-ui` at version `4.x`, then getting to your styling fix means pulling in a new major version of `noredink-ui`. This breaks all `TextArea` widgets across the project, so those will need to be fixed before you can do anything else, potentially a big effort.
To prevent these big Yaks from suddenly showing up in seemingly trivial tasks we prefer to avoid breaking changes in the package. Instead when we need to make a breaking change in a widget, we create a new module for it `Nri.Ui.MyWidget.VX`. Similarly, when we build custom elements in JavaScript we create a file `lib/MyWidget/VX.js` and define a custom element `nri-mywidget-vX`.
- Copy the contents of `Nri.SomeModule` and its tests to `Nri.Ui.SomeModule.V1` in `noredink-ui`
- Publish!
- If you feel confident upgrading pre-existing usages of the widget, switch over to it everywhere!
- If the new version introduces big changes and you'd rather keep the old one around for now, rename `Nri.SomeModule` to `Nri.DEPRECATEDSomeModule` in the monolith and start using `Nri.Ui.SomeModule.V1` where you need it
## Phasing out old versions
Our goal is to gradually move to the newest version of each widget, and remove the old versions when they are no longer used.
This means:
- We should avoid introducing new references to old versions of a widget
- When touching code that uses a widget, prefer upgrading to the latest version
- If you introduce a new version of a widget, please consider taking the time to upgrade all previous usages
- If for some reason this isn't feasible, create a story in your team's backlog so that you can prioritize it separately without disrupting your current work
- You can delete an old version of a widget when there are no usages left
- Currently, `noredink-ui` is used by the monolith, CCS and tutorials
- Note: this will be a major version bump, so you may want to batch deletions together