chore(packages): lock dependencies versions

[dhruvdutt]

What kind of change does this PR introduce?
Pin dependencies

Did you add tests for your changes?
N/A

If relevant, did you update the documentation?
N/A

Summary
Locking dependencies as per discussed on #697

Does this PR introduce a breaking change?
No

Other information
Closes #697

[webpack-bot]

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

[evenstensberg]

Is the npm run docs and npm run format commands working correctly?

[dhruvdutt]

Yes, both are working fine.

[dhruvdutt]

@evenstensberg Let me know if anything else is needed. Let's get this merged. 🚀

[milesj]

Why was this change allowed? Now all downstream consumers are going to have duplicates of all their modules since these are fixed versions.

[ematipico]

Mainly because of this event: https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/

We believe all libs should lock their versions of the dependencies to low down the likelihood of these events.

[evenstensberg]

Bazel and Angular is doing the same thing, this is ok

[dhruvdutt]

webpack, webpack-cli are anyways going to be devDependencies for most applications so it shouldn't matter anyway.

[milesj]

@ematipico That's nice and all but that can easily be avoided without having to lock all dependencies.

You're now in the scenario where this package will never receive any bug fixes for transitive deps without the package deps being manually updated. So unless you're going to do a dependency audit on a weekly basis, this does more harm than good.

[ematipico]

@ematipico That's nice and all but that can easily be avoided without having to lock all dependencies.

How?

This is the power and the weakness of npm. If we need a fix, we can simply set a bot and that would help. On the other hand an hacked package takes a lot (even a month) to get detected. I believe it's better to be safe and secure. But if you have other solutions, let's evaluate them!

[milesj]

@evenstensberg Unless it's part of a build process, most of their packages in the GitHub source use ^ versions. Same goes for React, Vue, Babel, and more.

@ematipico I could say the same thing about pinned versions... How do you know the version you pinned to is safe and secure? What if it's revealed a month later to also be problematic? This argument goes both ways but is also a personal opinion. So I suppose this discussion is over.

Ironically I will now have to pin this to a previous version.

[ematipico]

React and Vue don't have direct dependencies.

Anyway feel free to terminate the discussion, although I asked you what's your alternative solution!

The event-stream issue was caused because a person took advantage of unpinned dependencies (of dependencies, etc.) and people lost money! What's the less evil?

[milesj]

@ematipico

• Not use NPM packages for such minor functionality.
• Rely only on NPM packages from more credible owners (like orgs, foundations, etc).
• Pin untrusted packages, not all of them.

I'm hoping with the new GitHub registry, a lot of these problems will go away as the artifacts now sit alongside the source code and are verified and signed before publishing. Bad actors will always be thing but being entirely proactive isn't a perfect solution.