Monorepo containing Remix frontend for thunderstore.io and reusable UI components.
yarnworkspaces manages the packages in the monorepo (seepackageskey in basepackage.jsonfile) and handles dependency installation/deduplication.preconstructautomates building and linking the packages within the monorepo. Instead of using relative paths, local packages can be imported as if they were installed via a package manager.- Packages can be linked locally by running
yarn preconstruct dev, but this is handled automatically bypostinstallhook, so developers don't need to worry about it.
- Packages can be linked locally by running
// first time setup
git clone git@github.com:thunderstore-io/thunderstore-ui.git thunderstore-ui
cd thunderstore-ui
yarn install
// start Remix dev server
yarn workspace @thunderstore/cyberstorm-remix dev
That's it. Changes done to apps/cyberstorm-remix and
packages/cyberstorm should both be automatically visible at
[http://localhost:3000/].
// production build, assumes yarn install has already been run
// build packages/* with preconstruct
yarn build
// build and start Remix prod server
yarn workspace @thunderstore/cyberstorm-remix build
yarn workspace @thunderstore/cyberstorm-remix start
Solution: Enable developer mode in windows settings. See preconstruct/preconstruct#381 for more details
Solution: Downgrade yarn to a working version by running
yarn policies set-version 1.19.0. See
yarnpkg/yarn#8405 for more details.
To add new dependencies to existing packages, simply run something like:
yarn workspace @thunderstore/cyberstorm add react-table @types/react-table
Template
This repository includes a templated package generation script, powered by plop. The templates can be found in ./plop/package and should be updated if the requirements for new packages change.
Behavior of plop is controlled in a single JS file at ./plopfile.mjs
Generating
To actually generate a new package stub, simply run yarn run plop at the
root of the repository. You should be prompted with a handful of questions after
which a new package is created.
VS Code may have problem detecting installed packages in this monorepo/workspace setup. Installing Monorepo Workspace extension may solve them.
Storybook provides a sandbox to build UI components in isolation, without having to start up the whole service stack. Additionally it showcases the existing components, promoting reusability.
To start Storybook, run yarn workspace @thunderstore/cyberstorm-storybook storybook.
Storybook can then be accessed at [http://localhost:6006/].
When creating new components for @thunderstore/cyberstorm, add stories for
them by creating files under apps/cyberstorm-storybook/stories. See the
existing files for examples.
To upgrade Storybook when it informs you about new version being available, run
the given npx sb@latest upgrade command in apps/cyberstorm-storybook
directory.
Chromatic is used as a part of CI pipeline. It hosts Storybook, and detects visual changes to any stories. These changes needs to be reviewed before a related PR can be merged. The workflow is:
- Commit and push the changes as usual.
storybook-chromatic.ymlAction builds and uploads a new version of our Storybook to Chromatic. Note that this step only fails if there's error building or uploading the Storybook - any changes to components are not important at this point. - Create a PR as usual.
- If there were visual changes, GitHub will show a pending action: "UI Tests Pending — 10 changes must be accepted as baselines." Clicking the Details link will take you to Chromatic, where you must review and either accept or reject the changes. The PR can't be merged before the changes are accepted.
yarn workspace @thunderstore/cyberstorm-storybook chromatic can be used to
manually upload a Storybook to Chromatic, but this seems unnecessary since we
have it automated. To use the manual method, CHROMATIC_CYBERSTORM_TOKEN env
variable needs to be set (in the repo it's stored as a Secret for Actions).
The build configuration for some apps is included in the
docker-compose.build.yml file, making building of the services simple.
You will need to ensure all configured secrets are present before building
with docker compose. Currently the only required secret is the .npmrc file,
which should include authentication to the font awesome private registry. See
Font Awesome documentation
for more info on how to authenticate with npm, and then copy the ~/.npmrc file
it generates to the ./build-secrets directory.
Build secrets are unsupported in the docker-compose python package, you must
use the built-in docker compose subcommand instead.
Once the build-time secrets are available, building the services is as simple as running:
docker compose -f docker-compose.build.yml buildPre-commit enforces code style practices in this
project. Choose your preferred
installation method and then run pre-commit install to enable Git hook scripts. Pre-commit will now automatically cancel
your commits if any problems are detected, and autofix them. Stage the changed
files to your commit and re-run the commit command.
Pre-commit can be disabled for a single commit with --no-verify option, but
note that CI also runs pre-commit and will fail if any problems are encountered
at this stage.
