[91] update packages to resolve deep dependencies

[justincorrigible]

Closes #91, supersedes #90, #85 and #93.

[justincorrigible]

typo

[justincorrigible]

This is necessary in the latest version of TypeScript.

Looks like the maintainers walked themselves into a corner... still trying to figure everyone's way out of it.
microsoft/TypeScript#29131.

other people with the same issue:
microsoft/TypeScript#41563
microsoft/TypeScript#11498
microsoft/TypeScript#8516
microsoft/TypeScript#3356
microsoft/TypeScript#4260
DefinitelyTyped/DefinitelyTyped#6091

(Ignore my tone, I'm biased)

---

edit: According to this TS changelog from 4 days ago, this is not a bug but a "feature". 🤦🏻‍♂️
And they're breaking the internet with it.

[ciaranschutte]

the "preinstall": "npx npm-force-resolutions" will change the package-lock.json on every npm i but also every npm ci which I don't think we want happening for CI. npm ci shouldn't modify files as far as I'm aware (https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci)

Seems that npm-force-resolutions is a way to do yarn style package resolutions. I'm worried this is breaking the npm way of doing things. Maybe we should just fix the issues in the package-lock.json similar to dependabot?

Just my cents, let me know what you're thinking and if I can help @caravinci

[justincorrigible]

Edit: ignore this comment. Modified the PR to disallow npm ci from changing the lock for those resolutions unless instructed to.

---

You're 100% right, if that's the case! Updating the lock is one of the functionalities expected from npm ci, therefor automation shouldn't be using that to begin with (unless intended for some reason? ¯\(ツ)/¯ ).

Thankfully, we don't suggest using that command anywhere in the documentation, nor have I been able to find it being used in the automation scripts (which as a side note, did help me realise the dockerfile strangely uses yarn, even though this app doesn't have a yarn lockfile.)

As for the resolutions approach, I wasn't aware npm-force-resolutions changes the lockfile every time, apart from the time that gets committed in the repo. If we set the resolutions to a specific fixed version, there's no reason why the versions would change back to vulnerable or incompatible ones; even if the lock does change upon install.
Having a bit of trouble finding references to other people seeing the same issue without npm ci. However, I do remember reading something against changing the lockfiles directly, like most other autogenerated code. This approach tells npm do its job the best way it can.

Rather than using this package, or even changing the lock directly, the ideal scenario here would be as npm-force-resolutions themselves puts it in their documentation:

WARNING before you start
The use case for this is when there is a security vulnerability and you MUST update a nested dependency otherwise your project would be vulnerable. But this should only be used as a last resource, you should first update your top-level dependencies and file an issue for them to update the vulnerable sub-dependencies.

I've seen cases in which updating only the deep inner dependencies has actually broken the top-level ones, because of breaking changes and compatibility. Thoughts?

[justincorrigible]

Update: After locking down the exact resolution versions, not even npm ci is updating the lockfile.

Apart from effective, this approach makes it easier to maintain resolutions later keeping package.json as the single source of truth; and delegating the lock generation to npm, where it belongs.

---

npm audit shows 0 vulnerabilities using Node v13.14.0

[justincorrigible]

deprecated past graphql-compose@3

[justincorrigible]

deprecated past graphql-compose@6

[joneubank]

Thank you Justin!