npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@rocketmakers/infrastructure

v0.0.0

Published

Boilerplate for building rocketmakers npx scripts

Downloads

3

Readme

@rocketmakers/infrastructure

Sets up standard infrastructure for Rocketmakers projects.

Contents

Development

The project assumes you use the following git flow:

  • feature branches - Local development branches
  • develop - Main development branch on origin
  • release - Published branch

Before pushing any branch, the project is built using make, tested with jest and linted with eslint on your local environment. If any of these fail, the push will be blocked until they're fixed. Your push will also be blocked if the commited built files don't match the artefact build from commited source code.

Test pipelines are run on every pushed branch, which test the same as the pre-push check, across supported node versions (currently 12, 14, 16 & 18).

Merge requests should be made to develop.

Testing npx scripts

You should write unit tests in the _tests folder to test the functional behaviour of your scripts. As noted above, these will be run frequently to ensure that breaking changes don't slip in.

As well as unit tests, it is possible to test npx scripts in anger, by locally globally installing them:

> npm i -g
> npx . infrastructure
Hello, world!
> npm un -g

Release process

There are pipelines set up in the boilerplate to target the branch release. When you are happy with your project and want to push it to npm, there's a few steps to complete.

Initial npm publish

You have to do a manual initial publish to npm to set up the project on their end.

First, find someone to add you to the rocketmakers organisation on npm - ask in the #developers channel if you aren't already. Next, make sure you are logged into npm on the command line. To check if you're logged in already, run npm whoami, if not run npm login and follow the steps. You will be emailed a OTP to login.

Then, on the command line run

npm publish --access public

This will push your local branch(!) but connect it to the repo. We have to mark this initial push as public, because scoped packages are private and paid for by default.

Versioning

With appropriate setup, this project uses commitizen to enforce conventional commits. Thanks to this, there is automated version bumping available. Run npm version to update the version number in appropriate places. This will also generate a change log in CHANGELOG.md, according to the commit messages. Run this before merging to release, as the release pipeline will fail if it attempts to release a version number that already exists.

Further releases

After the project exists on npm, merges to the release will automatically run a pipeline that tags git, pushes to npm and publishes documentation to docs.rocketmakers.club. When you want to release, make a merge request from develop to release, and once it is merged, sit back and wait for the pipelines!