It appears that the intention of including `npm-check-updates` in this
repository was to provide an easy way to update dependent packages from the
console. This was originally introduced in [Ref 0].
Unfortunately, the `npm-check-updates` package has an explicit dependency on
`npm@3`, which means that it includes the entire `npm` in its
`node_modules`.
I originally observed this when analyzing the test failures in [Ref 1] and
[Ref 2] which indicated (in its npm error) that the npm version was v3.10.10.
The explanation for this is relatively straight-forward: Older versions of
npm uses an nested tree of `node_modules` directories while newer versions
hoist `node_modules` (i.e. flatten) to the highest location possible and
only nesting dependencies to meet conflicting version constraints.
Unfortunately, that means that once `npm@3` was installed by the newer
`npm@5` as a dependency of `npm-check-updates`, it was hoisted to the
top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which
directly call `npm` commands on the nested packages, as is done on this
monorepo (with, for example the `postinstall` script which runs `npm run
compile` in each of the server middleware packages). :face_palm:
Overall, this package doesn't seem to provide enough value for us to
continue to include it, especially since we have Renovate - coupled with the
same information being available from `npm outdated` and `npm update`
commands. I'm not sure why we would want to install newer versions than our
"package.json" allows.
Futhermore, looking at the issue tracker on `npm-check-updates`, I'm
assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on
this repository recently and _possibly_ even a bizarrely corrupted npm cache
I encountered recently (though admittedly, that could be a stretch).
See also: [Ref 4].
[Ref 0]: https://github.com/apollographql/apollo-server/commit/d7ca07f7
[Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915
[Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7
[Ref 3]: https://github.com/tjunnone/npm-check-updates/issues/420
[Ref 4]: https://github.com/tjunnone/npm-check-updates/issues/423
Ignoring the fact that the `.js*` was already _inclusive_ of `*.json`, we no
longer want `*.json` files linted (see [0] for more information), and I'm
not even sure why we would want to cover `*.md` rather than just `*.md`
(planning for a future markdown format?).
[0]: d4becdf6be
With a lack of comments and a fairly strict structure, it's arguable if JSON
files were ever meant to be pretty, but the method we're using right now is
a bit futile, especially considering that tools that we use to automatically
update JSON (specifically, package.json) don't run prettier themselves.
The most problematic rule is the 80 characters line limit.
Lines in JSON can be wrapped in, at most, one place: after the colon in the
key. This means that as soon as a single npm-script declaration exceeds the
line-length rule a second time, it can't be wrapped again, resulting in a
violation of the very rule being enforced.
Clearly, I've always thought that prettying JSON is a bit silly, but the
straw that broke the camel's back here is automated package.json changes by
bots which update the repository via their automated PRs.
Perhaps in a day where the JavaScript package manifest finds a new file
extension (.js?, .yaml, .toml?), it will be able to reap the glitz and glamour
of being eloquently formatted, but until then we'll have to use long-line
wrapping in our editors.
...or shorten our npm scripts.
* Pin `lint-staged` to maintain Node.js 4 support.
The newer version of `lint-staged` (v7) drops support for Node.js 4, a version of Node.js which is still under Maintenance LTS support and therefore we still need to test against. Since this npm would be used in our Node.js 4 test matrix, it's imperative that we not jump to v7.
