@balupton proposal for maintenance

[balupton]

Browsing through the browserify repos, these are obvious maintenance tasks that I've spotted:

metadata:

• inconsistent formats in readme.md/readme.markdown files
  • broken/missing badges
• missing/inconsistent changelog.md/history.md files
• missing/inconsistent documentation
• missing/inconsistent contributing.md

code:

• only 5 repos had automated dependency updates, none with automation for merging, causing the PRs to go stale over years, and security issues in the outdated dependencies to go unaddressed until rare manual updates
• inconsistent/missing ci testing
• no ci publishing, so all builds are require manual publishing (manual publishing doesn't provide transparency of which commits were published nor that the publishing wasn't tampered; manual publishing also means that any one of the many publisher keys could be compromised for a bad outcome)
  • github actions doesn't test on node <16, so unless people are manually testing earlier node versions, then no guarantees the package.json:engines:node is correct
• no typescript types

All those metadata tasks can be automated and made consistent with projectz, and all those code tasks can be automated and made consistent with boundation. These automations is how I publish engine-compatible and verified up-to-date releases for all the 100+ @bevry packages within 5 unattended hours, which solved the hundreds of Tidelift tasks across those packages automatically.

I'd be keen to solve these tasks for the browserify repos, perhaps starting off with one or two, then to whatever others people are okay with me applying them on.

[balupton]

I will begin work on this proposal next week.

[ljharb]

Let’s do them all as pull requests tho so they can get some more eyes :-)

Also, i prefer to stick to manual publishing; ci publishing is one-factor and is thus inherently insecure.

[balupton]

For @bevry the ci publishing happens via a bevryme npm bot which keys is only available to the ci, allowing the benefits and reduced risks in the OP. But no problem, I can skip that aspect of the proposal.

PRs, no problem.

Perhaps we can call sometime and I can show you the Bevry flow.

[ljharb]

I'm also skeptical about just wholesale adopting whatever you're using in bevry; I've got a lot of existing automations in my 450+ packages as well. Happy to hop on a call.