Discontinuous, in that not every package has a unique version at every numerical increment. Here at Stateful, for our multipackage monorepos, we use something called Discontinuous Semver. How do we build a process that, by its very nature, eliminates the opportunity for developer error in this situation? Discontinuous Semver This is a lot of process, and humans will get it wrong. Every time pkgA is changed, now, the developer needs to remember to also bump the latest version on pkgB, modify it’s release notes, and perform other tasks. If a more permissive semver rule is used, like >1.0.0 or even *, then additional burdens are placed on top of the developers. But this is a lot of work for a small team! Especially if both pkgA and pkgB are owned by the same engineering team, with packaging being used to allow reuse of a component between multiple build artifacts. Usually, the maintainers of pkgB would decide on some restrictive semver rule like ^1.0.0 so that patch level changes are maintained, but functional or generational changes are not automatically adopted. Traditionally, we’ve answered this question using Semantic Versioning, where major, minor, and patch version numbers each have localized meaning within the version history of a particular project. Also, how do you manage release notes and communicate impactful changes to your customers, both internal and external? Example: Continuous Semver How do you manage versioning, though? Some tools are unopinionated, others like lerna are heavily opinionated. These are popular and reasonable choices for starting a new family of projects. There are a wide variety of tools out there that support intersecting monolithics with traditional package.json nowadays, including yarn, npm 7, Turborepo, and lerna. Javascript and Typescript are particularly inclined to this many-into-one project architecture, as build artifacts may include ReactJS apps, CLI tools, or serverless functions. Monolithic repositories for source code are a well studied topic in this era of Javascript packaging, but are especially valuable when deploying monolithic services bundles composed of many projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |