Versioning strategy for npm modules
It is important to be able to bump the version of a npm package without side effects.
UI library case study
For a small React project a UI library is created. The library is maintained in a npm module with a semantic version. Each time the library changes the module is updated.
Over time the library grows to 30 components and is used in 5 projects. When a project requires a change the library is updated and the project is updated to use the latest version.
For the case described here this works well except for one project. This project uses the oldest version of the library and is never updated because of the many changes between the oldest version and the latest version of the library.
To overcome this deadlock situation the single library module is split into 30 component modules. The project with the oldest version of the library can now update the version of a single component.
Large modules
UI library
A lesson from the UI library case is that large modules have the risk of creating deadlock situations. This is especially true for actively developed modules because upgrading from the oldest to the latest version has a lot of impact.
Project module
The project module is the module on the highest level. This module is often overlooked when splitting into submodules.
The risk of a large project module is that updating a dependency potentially has great impact. The larger the project and the more the dependency is used, the harder it is to oversee the impact.
Split modules
Split up a module into submodules as soon as the module becomes too hard to update.
Component versions
Latest version
The UI library case shows that splitting up into component modules is a solution for the deadlock situation.
The major drawback of individually versioned components is that a component with version 1.8.4 looks older than a component with version 3.0.0 while in reality this may be the other way around.
Library version
The solution to the individual component versions is to maintain a single library version for all components. When a component updates, the library version is used to calculate the new version. Both the component and the library are set to the new version.
Monorepo
A monorepo can do exactly that. Tools like Lerna and Jmmake can be configured to version the packages as required.
Use a monorepo
Use a monorepo to make sure the latest component also has the latest version.
NPM7 and @npmcli/arborist
@npmcli/arborist is a powerful library that handles the new npm 7 workspaces. This blog is about a simple make tool that uses the library.
Comparing React app, Nextjs and Gatsby
A new React project starts with a React toolchain. Main tools in the chains are SSR, React server components and GraphQL.
Versioning strategy for npm modules
It is important to be able to bump the version of a npm package without side effects.
React component themes and CSS variables
Creating React components with flexible themes by using CSS variables.
Content modeling with variants
The efficiency of a variant field in a content model.
Documentation
Documenting a software project is challenging. Here's a few simple guidelines that help a team writing clear documentation.
Javascript history
In 1986 David Ungar and Randall B. Smith developed Self at Xerox PARC. Inspired by Java, Scheme and Self Brendan Eich created Javascript in 1995.
On Javascript transpilers, bundlers and modules
There's Javascript transpilers, modules, bundles and bundlers. This is a brief overview of all of these.
Agile Scrum
The Agile Scrum framework is flexible enough to be used in many different ways. Here's one way of working.
Contentful, Netlify and Gatsby four years later
What did we learn from using Contentful for four years?
Typescript interface for React UI components
How to define an interface for React UI components that prevents breaking changes.
What happened to Wheelroom?
Founded in 2018. Started to fly in 2020 and abandoned in 2021. What happened?
Naming React components
What's in a name? A clear naming strategy helps developers communicate. Most devs rather spend time writing component code than wasting time on a good component name.