Bevry has over a hundred npm packages, which currently garner over 500 million installs a month. Automation of all of this would be infeasible done entirely manually, as such, we make us of heavy automation. The only things that we have to manually maintain is the code itself inside the source/ directory, and the usage instructions at the ## Usage section inside the README, everything else is done for us.
First, Boundation is used to scaffold npm and web projects (such as Vercel projects), according to the desired feature set and technologies (TypeScript, JavaScript, CoffeeScript, etc), which sets up the project structure, dotfiles, documentation, continuous integration and deployment, and the setup of our other automation tools.
Boundation also tests our packages against multiple Node.js versions using Testen, ensuring our compatibility is accurate and if down-compiling is possible to make compatibility of a desired Node.js version, it will do so.
https://giithub.com/bevry/testen
When scaffolding the project using Boundation, it will ask you if you want to configure GitHub Actions. If you select yes, it will ask for the needed env variable values for your specified technologies. It will then configure the appropriate scripts from Bevry’s Actions accordingly.
There are numerous scripts there, our favourites are:
-
bevry-actions/surgewill be utilised if you specified documentation or a web project. It will deploy the compiled and successfully tested project to surge, with URLs for the commit, and if applicable the tag or branch. You can see this in action for the Daet package; here’s the latestmasterdocumentation, and the version 1.0.0 documentation, and a the docs for a specific commit. This also allows one to serve your project with the correct mimetypes. -
There are also scripts for various deployment services, such as
bevry-actions/npmto deploy the successful tag builds to npm. Allowing our git maintainers to simply publish a tag and have it published to npm if the git build passes, no more waiting on the npm owner or sharing npm keys with each other.
But you don’t have to worry about any of details, as again, Boundation handles it all for you, prompting you for the appropriate details for your technology and target environment, and configuring everything based on your specifications, so you can focus purely on your code.
Testing doesn’t end there. If you are using ESLint, which Boundation would have automatically selected if you chose JavaScript or TypeScript, then Bevry’s eslint-config-bevry will be used, which automatically detects what technology your project uses, and adjusts the rules and linting packages accordingly:
That’s linting sorted, testing sorted, continuous integration sorted, and even continuous deployment sorted. But what about all that README fluff? We have that covered too! In fact, @balupton even gave a talk about it:
For this, we utilise a tool called Projectz. Which generates and maintains the README according to what is specified package.json file. It even generates and maintains our LICENSE file, and even our BACKERS file if we want. And even pulls in our github contributors directly into the relevant sections. And again, Boundation sets it all up for us.
It also uses Badges to render all those beautiful and useful readme badges that we have come to love but hate to maintain. Which Boundation will again automatically configure for you.
Now what if you are deploying a npm package to multiple environments? Such as the web, or new node versions, and old node versions? And what if you are writing in ESNext but having to support ES5? In that case, it really doesn’t make sense why people on modern environments have to use compiled ES5 code, instead of your source ESNext code. Or what happened if you used one feature, that the web browser environment doesn’t support, but node does. Well in that case, you can utilise Editions.
Editions is a package.json field for specifying which editions your package is deployed with. It can be used by the Edition Autoloader to automatically load the best edition for a user’s node.js environment, or even by bundlers/packers to use the closest to source edition for compilation, rather than compiling compiled code again and again. And you guessed it, Boundation automatically detects what editions are necessary, and configures it all for us.
So what do you think? Is it time to start maintaining only the source/ and ## Usage sections of your packages, with everything else automated, freeing up time to maintain hundreds of packages.
Get more done. Use Boundation, or use each tool independently. It’s up to you.
Another special shoutout, is our Dorothy project, which allow complete automated installation of development environments on MacOS and Linux, as well as per-user customisation of what gets installed. Special shoutouts to its secret, edit, and setup-git commands: