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.
Primarily because the results that prettier is giving on Travis are not the
same as those that are exhibited locally. Namely, the result of running the
`npm run lint` command locally returns different files than on TravisCI.
This makes it almost entirely impossible to determine what is wrong with the
files. It's likely enough that it's running in post-commit, but I'd be
happy to re-introduce this commit if someone can figure out what is wrong!
For now though, it's interfering with the ability to merge PRs.
As another option, perhaps CircleCI workflows would allow us to have
separate fail badges for Lint tests rather than testing the linting in every
Node.js version of the build matrix and polluting the true success and
failure of the unarguably more important tests themselves (rather than the
formatting of the code which is being tested).
