[RFC] Workflow + Tooling for Package Maintainers

[thescientist13]

Overview

For projects and packages within the NodeJS ecosystem (especially those with high impact to the community), affording maintainers the tooling and workflows to confidently publish and distribute packages to their consumers has become an identifiable and growing desire for the community at large.

During the Collab Summit session for the Package Maintenance WG, there was a great discussion around the topics of tooling, upgrades, workflows, process, automation, security, and how these ideas can be explored, discussed, implemented, and shared with the community at large, and hopefully being able take advantage of, and improve, existing tooling and workflows already available. (and maybe even making some new ones! 🎉 )

Proposal (WIP)

The proposal here is to explore the ideas discussed during the session and follow those threads where they may lead, in particular around finding opportunities around automation, tooling, and ultimately, ease the burden of maintenance for for maintainers.

Of great interest is cross pollinating tooling being developed and maintained by the NodeJS Release WG, in particular looking at tools like citgm, which the NodeJS teams uses to assess the impact of changes on the wider community at large, by building certain projects against new / nightly builds of NodeJS itself.

For example, a project like Express may want to build against key projects and packages within its own ecosystem on a nightly basis against master, to ensure there aren't breaking changes in a scenario outside of an expected semver major release. (the interval used is just an example)

Thoughts / Questions / Considerations

• Given the high visibility and foundational support of NodeJS, it seems like there is a lot of opportunities to use and build off of what the NodeJS Release WG is already doing either by:
  1. increasing visibility of existing tools already used and automating more of the NodeJS process
  2. Sharing the results of those efforts with the community, ideally through CI based tooling (e.g. GitHub Actions, see below).
• How do we measure and determine what's worth automating and also what could be leveraged from GitHub, like with GitHub Actions, or maybe in conjunction with npm, so that as many projects as possible can benefit with little lift / effort on their part, but with immediate value add a reduced burden to their project's overall maintenance.
• What expectations from the community itself may we want to assert, e.g. if we build Express nightly, but all the ecosystem tools are mocking all the Express APIs, how effective will nightly citgm based builds actually be?
• Are there opportunities for parallelization of our efforts here? It would be great to think of a few different approaches and let teams / groups / WG try them out and report back, and we can guide our efforts based on those results.

---

Anyway, this is just a start and hopefully I captured the spirit, ambition, and voice of the room and so happy to help get this conversation started. I am personally looking to get involved in the NodeJS release process and trying to help with automation there, and would be happy to help bridge and be a liaison between these two WGs (Release + Package Maintainers) and try and maximize the efforts (and minimize the overlap) of both teams.

Thanks for a great event and looking forward to continuing the conversation! 👋

[mlrawlings]

To add to the above, specifically on the topic of tools to test against a project's ecosystem:

Ensuring you don't break dependents

• "Canary in the CI" - a GitHub app that creates a network among dependencies and their dependents (very much a WIP, just threw this up to add to the discussion)
  • PROS: Uses dependent's test environment, so integration-type tests will work without additional effort
  • CONS: Tied to GitHub, Requires opt-in from dependents
• A CLI tool to pull down dependent's tests and run them (@BethGriggs, you were working on something?)

Ensuring your dependents don't break you

• vertest - pull down dependency versions in your package.json's semver range to test compatibility with multiple version combinations of your dependencies
  • PROS: great for projects designed to work with multiple versions (especially major versions) of another package
  • CONS: can create a very large test matrix