Maintenance and traceability of the spec

[Wojciech Trocki]

As every document or recomendation it is sometimes really hard to maintain it considering number of the packages that will be included in the recomendations.

Packages can get:

• Outdated
• Deprecated
• Stopped from being maintained.
• No longer work with the rest of the ecosystem (Node.js version etc.)
• Go against some values and rules

To keep reference specifications maintainable we usually trying to automate some of this task (as recurently going thru the recomendations will be unrealistic and documentation will outdate/deprecate over time (been there).

Solution: Utilize already existing ecosystem of bots and list packages in the way that they can be seen in one place and automated.

Approach nr1

Each node.js package we recommending ending up in the root package.json.
We configure dependabot, renovate, nsp and other IBM and Red Hat bots (Like license checks)
to run on each PR and also on releases

Approach nr2

List packages in custom json file that have them categorized etc. then we can build some scripts for checking some metrics on those packages

I would think that initially we just need something like this:

{
  packages:{
     "express":{
		// To express categories
      	category: "REST API",
		// To express flavours
		labels: ["General Purpose", "Platform", "IOT"],
		// To losely define what version was checked or recomended
		version: ">=5.0.0",
		// To include some packages that we recommend that will work only with express.
		subpackages: ["express-session", "keycloak-connect"]
     }
  }
}

CC @mhdawson @lholmquist

[Wojciech Trocki]

The created package that will support our use cases and enforce standards:
https://github.com/wtrocki/package-catalog

This can be extended for license checks and other things.
I have created an upstream package (as this is a kinda generic problem) but it can be used.

I would love to see if we can integrate that with the license check command and others

[Michael Dawson]

@lholmquist what's the overlap between https://github.com/wtrocki/package-catalog and https://github.com/nodeshift/oratrix

[Helio Frota]

Question: Why not to include package-catalog inside oratrix ?

oratrix was designed to grow and we are also using commands directory so I believe more code can be added following the current structure pattern (which already have test, ci, coverage, lint).

Also we have licenses scan feature in this branch: https://github.com/nodeshift/oratrix/tree/with-licenses-search

[Wojciech Trocki]

@helio-frota thank you so much for your reply. I would love to collaborate with you on this.
I could not find oratrics. Will wait for @lholmquist reply. Happy to contribute - we need to move this one forward :)

[Helio Frota]

@wtrocki thanks for the words : ) you are welcome. 😃

[Lucas Holmquist]

@helio-frota @wtrocki sounds good to me. lets see how the integration goes

[Wojciech Trocki]

All good. Will PR soon

[Michael Dawson]

@wtrocki we are currently running npmcheck against the modules which are captured in: https://github.com/nodeshift/nodejs-reference-architecture/blob/main/npcheck.json.

Does this cover the checks you had in mind?

[Wojciech Trocki]

that solves issue. Good to close

[Michael Dawson]

@wtrocki thanks.