Suggestion: Tooling to assist maintenance errands

[balupton]

Travis CI recently informed me that I have over 800 packages using it.

I've done up the following tooling to assist in automating the maintenance of my packages as much as possible, they have been used for years, and probably others will find them useful:

• https://github.com/bevry/badges - generate readme badges
• https://github.com/bevry/projectz - automate readmes
• https://github.com/bevry/awesome-travis - travisci scripts for testing, publishing, deployment, etc
• https://github.com/bevry/boundation - scaffold projects with the above

If you have your own, post them too.

[ahmadnassri]

topic is too broad maybe?

e.g. does eslint apply here? and thus every type of "linting"

I would suggest a narrow definition of what "core maintenance" needs are and short list tooling recommendation to match

[balupton]

I would suggest a narrow definition of what "core maintenance" needs are and short list tooling recommendation to match

I guess it depends on how broad or specific this repo's initiative will be. For each best practice, there may be several automated tooling solutions, as well as there may be already some automated tooling solutions that people don't know about that could inspire a best practice.

Ultimately, if it is a better fit outside this initiative, then an awesome-maintenance list repo would serve this purpose well enough.

e.g. does eslint apply here? and thus every type of "linting"

Sure. eslint and prettier definitely help facilitate maintenance.

[vweevers]

• Automate updates: Greenkeeper, Renovate
• Lint to avoid bikeshedding: standard, hallmark
• Test on consistent node versions: verify-travis-appveyor
• Collect code coverage: nyc with coveralls
• Build and publish prebuilds for native modules (also reduces support requests): prebuild, prebuild-ci, prebuild-install, prebuildify, node-gyp-build
• Enhance workflow and communication: wip, project boards, keep a changelog

[vweevers]

an awesome-maintenance list repo would serve this purpose well enough

Perhaps accompanied by a guide that focuses on workflow; how to use the tools most effectively.

[ljharb]

Linting to avoid bikeshedding also includes any usage of eslint, but especially the airbnb config.

[MatthewHerbst]

Automated tooling that creates PRs with package updates can go a long way too to preventing bugs and security issues from spreading too far (so long of course as the PRs are addressed in a timely manner).

Ex (there are many such tools), this is just one I found googeling: https://greenkeeper.io/

Or even just add ing npm-check-updates runs to CI builds could be very informative for package maintainers.

[TheHollidayInn]

Would CodeClimate be a good link here: https://github.com/codeclimate/codeclimate? I've used this in similar tools to catch a good amount of basic code quality issues. If linting is not considered then nvm :P

[caraya]

In addition to listing the tools, we may need to add pre-requisites. For example, if you add Greenkeeper you need to have some sort of CI tool enabled for it to work. If you use Renovate then does your project qualify as open source or is it a personal project and you have to pay after the trial period (it's not the amount that matters but the fact that you have to pay).

Testing for bikeshedding depends on the tool you use and what preset is installed. We should encourage people to lint their code and provide alternatives rather than preach about single options. I also would like to see Eslint and its presets (Airbnb, Google, Standard) included in the linter section. Rather than bikeshedding, I would call it "code style consistency" or just plain linting.

Last thought on this. I think it's important to note that these are options and we're not advocating specific ones.

[hutson]

Last thought on this. I think it's important to note that these are options and we're not advocating specific ones.

I saw this discussion as a great opportunity to discuss tooling that lowers the maintenance overhead.

For example, I find it really helpful to maintain my packages using a dependency update tool.

I feel it would be really helpful to maintainers to suggest tools (and not a particular brand) that can help them maintain their projects and how it does so (how it can help them and the community)

[Eomm]

Maybe someone could create an awesome list and we could say to users:

We have talk about ci, testing, versioning, auditing, updating etc.. it is a lot of stuff, so check out this awesome list to choose the right tool for you
we have built these default settings if you want to use them

?

[balupton]

copy of my comment here #280 (comment)

---

FWIW

@bevry accomplishes the goal of this automatically for all of its packages, through the following pieces

• https://github.com/bevry/boundation enforces consistency against packages, including support for all the below, and including support for local testing on the package's specified node versions via https://github.com/bevry/testen
  • https://github.com/bevry/editions enables support for older node versions, as well as provides standardised data about the environments the package supports and what technology it uses
  • https://github.com/bevry/projectz enforces consistency of the meta files, such as the readme and package.json, and installation and license information, including badge information via https://github.com/bevry/badges
  • https://github.com/bevry/awesome-travis has several scripts such as
    • https://github.com/bevry/awesome-travis/blob/master/scripts/surge.bash which publishes the commit, branch, and tag to surge for browsing of docs and cdn
    • https://github.com/bevry/awesome-travis/blob/master/scripts/node-publish.bash publishes git tags to latest and master (as configured by NPM_BRANCH_TAG) to the next tag
    • https://github.com/bevry/awesome-travis/blob/master/scripts/node-install.bash ensures dev deps are installed with the desired node version, to enable tests to run even on legacy node versions
  • dependabot configuration to auto-merge passing dependency updates
• https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-upgrade runs boundation on a project, and publishes a new release - if the engines changed, publishes a new major release, otherwise a minor
• https://github.com/balupton/dotfiles/blob/master/.scripts/users/balupton/commands/boundation-all runs boundation-upgrade on all bevry's packages

[dominykas]

@balupton sounds like a cool set of tools! I think in the existing docs we have avoided making specific package recommendations, but instead we list several packages that do similar things. It would probably be useful to mention some of your tools in some of our existing guidelines, as well as providing alternatives?

[balupton]

It would probably be useful to mention some of your tools in some of our existing guidelines, as well as providing alternatives?

Sure, that's your discretion.

[wesleytodd]

@balupton, if you can identify places where your tools could be mentioned in the documentation we are building, it would be helpful to open PR's against those so we are sure to include them in the right places. I don't think those here will always know which of the ones you list are intended to fit where in the SDLC.

[balupton]

@wesleytodd seems the only page would be https://github.com/nodejs/package-maintenance/raw/master/docs/drafts/tools.md

[wesleytodd]

Great! The PRs should be simple enough then. Can we close this issue?