Source code

Reshaped can be used as a starting point for the teams building their own design systems to skip the implementation of the core features. Since most design systems have so much in common, this is a huge time saver for companies who don't want to waste time discovering the best practices and learning about pitfalls.

When you get the Pro license, you get the system's code in precisely the same state as we develop it. It means that you get access to uncompiled code of the components, their Storybook examples which you can run locally, an extensive test suite and the development environment that helps you adding new features. As you keep changing the source code of the components, you may also easily adjust the tests and examples you need.

Download the latest source code archive and unpack it in your local file system. You can use it as a separate repository without any additional setup or you can turn it into a package inside your own monorepo.

By default, we're using Yarn, so run yarn in the project to install all dependencies.

yarn build

Build the whole project, including a ESM build for the components, CJS build for the CLI, library bundle, styles, themes and storybook. You can also run each part individually if you only need to test a specific change.

To build the project, we're using a combination of multiple tools:

  • vite for building the library bundle and Storybook
  • tsc for building ESM and CJS output files
  • postcss and css modules for css files
  • Our custom node CLI for building themes

yarn dev

Start the Storybook with all component examples. It includes an accessibility plugin, custom controls for toggling content direction and color mode. We're building it using vite.

yarn lint

Run eslint and stylelint against the codebase. If your editor supports linting, you should see the errors and warnings as you change the code, so you won't need to run this script manually. When you commit any files in the project – we're running them autmatically against the updated files using lefthook.

yarn release

In case you need to release your package for internal use – you can use our release scripts. Most likely you'll want to update how they work, since probably you don't need a release process for the source code and instead of creating a .tgz you would publish it to your internal NPM registry.

There are 3 more scripts responsible for the quality assurance:

yarn test:unit

Run unit tests written with jest and react-testing-library. We're already providing you with tests for the components coming with the source code. You can modify these tests as you keep customizing the code.

yarn test:size

Run size-limit to check the bundle size after your local code changes. This could be very helpful to prevent mistakes with package imports and we're also providing a GitHub action to run this check on every pull request.

yarn test:vrt

Run visual regression tests using chromatic. Every component story you have in storybook automatically turns into a screenshot tests.

Note that we're using a Chromatic token from a .chromatic file which we don't include in the source code. To use screenshot testing, you need to generate your own token in Chromatic and create a file containing its value.

The source code for our React library includes a GitHub Actions setup that automatically activates with every pull request. This setup includes essential scripts: lint, build, and test:unit. These scripts ensure code quality, proper build, and functionality through unit testing.

For monitoring bundle size, we've integrated the size-limit GitHub action. This tool runs during pull requests and posts the results as a comment, making it easy for you to track any significant size changes.

Screenshot testing isn't included by default in each pull request. This is because its implementation depends on whether you're using Chromatic and the type of license you have. If you decide to include screenshot testing, you can easily add it by modifying the workflow files in the .github/workflows directory. This flexibility allows you to tailor the testing process to your project's specific needs.

While Reshaped has a standalone website hosting all documentation, pro license users get access to our Storybook environment. In case you're planning to add, update and/or remove component features – we suggest using Sotrybook for documenting these changes. Most of the time you should be ok with just adding examples for the new features, while you can also add markdown documentation as well.

With the pro license purchased, you will be receiving lifetime updates. So even after you start changing the original code, you will be able to look into the latest changes and learn their implementation details. It should help you stay productive with your system development and will help you adopt new components added to Reshaped.

For teams who want to make the most out of the source code updates, we recommend to only copy the source code of the components you want to customize. You can use other components directly from the Reshaped, which means you will be getting automatic updates for those components and can cherry pick the changes for the components you've modified.

Reshaped comes as a standalone project that works autonomously without any customisations. That means you can just push it to your private git as is and it will keep working, including its complete development environment. You can also publish it to your private NPM registry.

In case you want it to use inside your monorepo, you can move Reshaped into one of the monorepo packages and review the list of the dependencies used in the package.json file to remove the devDependencies already used in your project.