lockfile-lint VS betterer

Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities

I built a lockfile-lint (https://github.com/lirantal/lockfile-lint) that helps with ensuring that some of these trust policies are enforced.

And it is happening right now. Github is opening the GitHub Advisory Database to community submissions. Awesome community NodeSecure builds cool things like scanner and js-x-ray. There are also lockfile-lint, LavaMoat, Jfrog-npm-tools (and I am sure there is more).

An additional approach may be to use lockfile-lint, but you shouldn't just rely on this script entirely because there are other ecosystems than npm, and they may have similar issues.

Use lockfile lint to check changes in the package-lock.json which is typically not reviewed

We first took a shot at addressing this gradually using a tool called Betterer, which works by taking a snapshot of the state of a set of errors, warnings, or undesired regular expressions in the codebase and surfacing changes in pull request diffs. Betterer had served us well in the past, such as when it helped us deprecate the Enzyme testing framework in favor of React testing library. However, because there were so many instances of noImplicitAny errors in the codebase, we found that much like snapshot tests, reviewers had begun to ignore Betterer results and we weren’t in fact getting better at all. Begrudgingly, we removed the rule from our Betterer tests and agreed to find a different way to enforce it. Luckily, this decision took place just in time for Snoosweek (Reddit’s internal hack week) so I was able to invest a few days into adding a new automation step to ensure incremental progress toward adherence to this rule.

Check out the beast of a PR here (and yes, it took me three branches to get it right 😅)

I just released v4.0.0 of Betterer 🎉 (now with sweet new docs!) and it has a bunch of simplified APIs for writing tests. And just before I shipped it, I got an issue asking how to write a Stylelint test, so let's do it here and explain it line by line:

You may think that is a bad idea, and stops innovation and adopting new trends and technologies. I dare to disagree. New conventions can be agreed on, and when a new convention is agreed on, it should be used in the codebase from that day on. Either by refactoring the whole code base to follow the new convention, which should be doable if the previous convention was followed carefully, or by using tools such as phenomnomnominal/betterer to incrementally adopt a new convention, and stop anyone from adding new code that does not follow the newly agreed convention. It is equally important to document the agreed conventions and keep the documentation up-to-date over time in addition to making sure everyone on the team hears about and understands the agreed conventions.

I have a tool that I've been working on for a while, and debugging it can be kind of a pain - especially when it's running inside VS Code. It'd be nice to have an easy way to get information about what is going on when the tool runs, without having to manually write a bunch of debug logging code and release a new version. That means that the usual approaches are not going to work: