
Update in ajv package broke webpack - tyteen4a03
https://github.com/webpack/webpack/issues/8768
======
smacktoward
I love how the thread immediately devolves into confusion over whether the way
to fix the problem is to manage dependencies with npm or with yarn.

Never change, frontend community!

------
rigaspapas
This is what happens when you don't pin your dependencies, right?

~~~
ameliaquining
It's indeed a good reason for _apps_ to pin their dependencies; those that did
so presumably didn't have their builds broken by this issue. I don't feel that
pinning dependencies necessarily makes a whole lot of sense for _libraries_ ,
since it creates inflexibility and dependency duplication for app developers.
But opinions vary.

~~~
jessaustin
Wouldn't we consider the way that most people use webpack to be as an app, not
as a library?

~~~
ameliaquining
No, because you declare it as a dependency.

~~~
jessaustin
Is this a novel definition of "library"? To me, library code is called by my
code while my code is running. So, most libraries are dependencies, but lots
of dependencies are not libraries. Test, code coverage, or documentation tools
might be dependencies, or as npm would say instead _dev_ Dependencies, but
they are not libraries. Similarly, webpack is what we might call a build tool,
which is also not a library.

~~~
ameliaquining
I think it's just a semantic distinction, not a substantive one. The relevant
thing is indeed that Webpack is generally used as part of another build
process.

~~~
jessaustin
OK let's go with your definition. You're saying that "endpoints" may pin their
dependencies, but any package that is depended upon by some other package
should not in turn pin its own dependencies. ITT, I don't see support for this
proposition. 'rigaspapas observed that the problems described in TFA could
have been avoided through pinning. Presumably you're thinking of other
problems that could be _caused_ by pinning, but why would you think those
problems are any worse than causing the program to completely fail to
accomplish anything?

~~~
ameliaquining
Not necessarily worse, but more common. Diamond dependencies happen a lot,
especially in npm.

~~~
jessaustin
Diamonds are more common because node unlike many environments is absolutely
tolerant of them. Maybe this "wastes" some disk space, but otherwise this is
not a problem. It is orthogonal to actual problems like bugs in particular
package versions.

------
moltar
This is why I have a global npm config flag to install the exact versions of
packages. I think it’s a huge mistake to install “anything over X” versions or
even have that as a feature.

