Home

Bolt: Making Building React Components Easier

At @walmartlabs, we've gained major wins by splitting up react components into distributed libraries across git repositories instead of having a monolith.

Some of those wins are:

• Allowing developers to work fast in small, manageable codebases
• Ability to take dependencies on only necessary components
• Components are on seperate release cycles
• The ability to share common components through composability
• And my personal favorite: a common architecture/file structure that made it easy to create new components quickly that could be easily groked by anyone who'd worked on at least one component.

Overall, the wins were huge and the ability to focus on building react components was glorious.

One problem did present itself in separating out components:

A burden on the upkeep of configurations and tasks that should be run within each package.

This meant someone would have to go through, package by package and do minor (or major) updates to these configurations over and over again, but with potentially different results because of a bad "copy/pasta".

Enter Bolt!

Bolt was designed to do 3 things:

1. Provide the standard libraries and frameworks you use through the lifecycle of developing a react component.
2. Provide the scripts or tasks that every component should have available (test for instance)
3. Allows you to override those with your own scripts and still use bolt to run them

This keeps all of the standard stuff we do (such as webpack.config.js and npm run build-lib) abstracted away so developers can focus on the stuff they want to do (build awesome react components) while also giving them the tooling they need to run tests, lint their code and spin up development servers.

You can run a task by running bolt <task>.

The ones you're most likely to use all the time are:

• bolt demo: this will run a webpack-dev-server at port 8080
• bolt build: this will build your src directory to lib
• bolt test: this runs eslint linting and karma tests. If this passes, you can be sure your commit will pass in your Pull Request (assuming someone's setup a Jenkins CI for you)

If you add scripts to your project's package.json, bolt will opt for your script if it overrides an existing script for bolt or just run it the same as if you ran npm run <myscript>. This gives you two major wins:

• The flexibility to not be tied to bolt for everything, but always use bolt to run tasks
• The abilty to still have access to webpack, eslint and karma, so if you want to run those tasks with different arguments or configurations, you can simply call those in your script tag and run it as bolt <script> and it will leverage the existing dependencies supplied by bolt.

Environment Requirements

The team suggests using nvm as your node installation. With nvm, your global modules won't be saved to somewhere that requires sudo, so you won't ever have to sudo npm install something and any CLI tools in your project are added to your $PATH so you can use them as first class command line tools.