Update webpack-dev-server 3.1.9 -> 3.1.14

[Friss]

Small bug fix update https://github.com/webpack/webpack-dev-server/releases/tag/v3.1.10

Mainly interested in the new ability to pass writeToDisk option to webpack-dev-middleware

That option could be leveraged to solve #1070

[ianschmitz]

Do you mind bumping this to latest release? Should fix #6109

[Friss]

Bumped to 3.1.14

[ianschmitz]

Thanks!

[alexch]

4c7c3c5 updated the webpack dependency version but did not add a ^, thereby assuring that Murphy's Law will cause this "waiting for Godot to release" situation again.

Why not use "webpack-dev-server": "^3.1.11" or "webpack-dev-server": "~3.1.11" and allow us to automatically get future updates to webpack-dev-server with a simple npm update or npm audit fix ?

[Friss]

Pinning to a verison is safer and results in reproducible results for every install of react-scripts.

[mjziolko]

Except it's been 3 days without being able to use react-scripts. Sure, right now every installation of react-scripts is unusable while we wait for the patch to be published, but is that the situation you actually want?

According to NPM, that's a couple hundred thousand people not being able to build their projects, waiting on one person to push a fix that was published.

[robertvansteen]

@bradziolko what do you mean react-scripts is unusable? It's working fine for me.

[mjziolko]

@rovansteen Don't clone a new repo, create a new app with create-react-app, or git clean, because you won't be able to install react-scripts without this fix being published or forking the repo and fixing it yourself.

I am only running into this issue because I did a git clean a half hour ago.

EDIT: Furthermore, your source code is vulnerable to attackers while you wait for this fix to be published, as the vulnerability describes

[robertvansteen]

Well since you are only using webpack-dev-server the the vulnerability doesn’t really apply here. I set up a new project twice yesterday with npx create-react-app and that was working fine.

[mjziolko]

I'm not sure what you mean? The latest published version of react-scripts has a pinned dependency on the vulnerable version of webpack-dev-server.

[mjziolko]

Ah, I see what my issue is now. In an attempt to dance around the vulnerability I rendered my app unusable due to conflicting webpack-dev-server versions. So, projects should build and run normally, though the npm audit will throw a warning for the duration.

My mistake, though I think my arguments for allowing devs to update the minor version in cases like this still applies else we're running on high vulnerabilities for days without protection.

[robertvansteen]

I totally agree with you that in an ideal world the versions wouldn't be pinned and everyone would get non-breaking security & bug fixes when running yarn or npm. Unfortunately not everyone honors semver and this could break new installs of create-react-app when a dependency doesn't honor semver and breaks on a minor/patch update.

[alexch]

On Fri, Jan 4, 2019 at 5:43 AM Robert van Steen ***@***.***> wrote: I totally agree with you that in an ideal world the versions wouldn't be pinned and everyone would get non-breaking security & bug fixes when running yarn or npm. Unfortunately not everyone honors semver and this could break new installs of create-react-app when a dependency doesn't honor semver and breaks on a minor/patch update.

I don't mean to sound harsh, but if you pin to a particular patch version, you're the one who isn't respecting semver. A primary purpose of semver is to enable backwards-compatible bug fixes to be automatically propagated to all dependent projects via `npm update` etc. Pinning a library to a specific dot version might make sense for applications (whose owners have time and energy to monitor and repair conflicts), but not for libraries used by thousands of different apps, each with their own particular tangle of packages. Semver requires faith, or at least optimism, in the behavior of strangers. The system only works if everyone follows the rules. Will someone someday release a breaking patch or minor version of a popular library? Sure, but that will be their fault to fix, and in the meantime apps can temporarily pin to a known good release and life will go on. Unlike the situation now, when library X requires version 3.1.11+ of webpack-dev-server, and react-scripts requires version 3.1.9, and people break their build trying to do the right thing.

[Friss]

How about what happened with flatmap-stream and a minor verison had the vulnerability then a new major published without the vulnerability to cover the tracks?

If react-scripts didn't pin to an exact version something like that could target a library used by react-scripts and reach a lot more people.

While it has some inconveniences when this package isn't published frequently, the upsides to pinning to specific versions outweighs this negative. (plus you are still free to fork and have your own verison with non pinned deps!)

[robertvansteen]

Sure, but
that will be their fault to fix, and in the meantime apps can temporarily
pin to a known good release and life will go on.

That's not true because you can't pin the dependencies of CRA. I get your point but that optimism could result in CRA being broken for lots of people.

I think what's more important is that CRA is well maintained and that in a situation like this a new version will be released quickly. I don't really understand why that hasn't been done to be honest.

[alexch]

"You can't pin the dependencies of CRA" -- sure you can. If you add "webpack-dev-server": "3.1.11" to your project's top-level package.json then npm will try to use that version for all packages that depend on it, including CRA. Right?

I concede the point that if you're primarily worried about preventing malicious hackers from taking over projects and pushing malware under the guise of bug-fix patch releases, then the semver system won't work. It just seems illogical to me that in the name of preventing some unknown exploit at some point in the future, you delay current known vulnerabilities from being fixed automatically.

[gaearon]

Hey folks! I'm sorry if this is frustrating.

We have a policy of pinning the dependencies because otherwise things tend to break too often for our users. We're not strangers to semver but we err on the side of being more conservative than taking every top-level downstream patch automatically. We are an "integrating" package for many other ecosystems (Babel, Webpack, ESLint). Even small changes in one of them can break integration points that aren't necessarily covered by semver guarantee. If you want more control, you can always force a specific version to be used with Yarn resolutions (which let you override even react-scripts’s dependencies).

This is an intentional tradeoff. It’s not for everyone — but we have to make a decision, and this is the one I’ve chosen for this project. I understand if you disagree. It’s my fault that I haven’t heard about this problem sooner — the first time I saw a mention about it was 30 minutes ago. I would appreciate callouts on Twitter if you see me or other maintainers not responding to a specific issue. I also gave @ianschmitz publish rights now so we have more people who can cut an urgent release if necessary now.