Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update webpack-dev-server 3.1.9 -> 3.1.14 #6064

Merged
merged 2 commits into from Jan 2, 2019

Conversation

@Friss
Copy link
Contributor

commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 1, 2019

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

@Friss Friss changed the title Update webpack-dev-server 3.1.9 -> 3.1.10 Update webpack-dev-server 3.1.9 -> 3.1.14 Jan 2, 2019

@Friss

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

Bumped to 3.1.14

@ianschmitz ianschmitz merged commit 4c7c3c5 into facebook:master Jan 2, 2019

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
deploy/netlify Docs deploy preview succeeded
Details
@ianschmitz

This comment has been minimized.

Copy link
Collaborator

commented Jan 2, 2019

Thanks!

@ianschmitz ianschmitz added this to the 2.1.3 milestone Jan 2, 2019

Pluzu added a commit to brenger-nl/create-react-app that referenced this pull request Jan 3, 2019
Update webpack-dev-server 3.1.9 -> 3.1.14 (facebook#6064)
* Update webpack-dev-server 3.1.9 -> 3.1.14
Pluzu added a commit to brenger-nl/create-react-app that referenced this pull request Jan 3, 2019
Update webpack-dev-server 3.1.9 -> 3.1.14 (facebook#6064)
* Update webpack-dev-server 3.1.9 -> 3.1.14
@alexch

This comment has been minimized.

Copy link

commented Jan 3, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

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

@bradziolko

This comment has been minimized.

Copy link

commented Jan 4, 2019

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.

@rovansteen

This comment has been minimized.

Copy link
Collaborator

commented Jan 4, 2019

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

@bradziolko

This comment has been minimized.

Copy link

commented Jan 4, 2019

@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

@rovansteen

This comment has been minimized.

Copy link
Collaborator

commented Jan 4, 2019

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.

@bradziolko

This comment has been minimized.

Copy link

commented Jan 4, 2019

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.

@bradziolko

This comment has been minimized.

Copy link

commented Jan 4, 2019

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.

@rovansteen

This comment has been minimized.

Copy link
Collaborator

commented Jan 4, 2019

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

This comment has been minimized.

Copy link

commented Jan 4, 2019

@Friss

This comment has been minimized.

Copy link
Contributor Author

commented Jan 4, 2019

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!)

@rovansteen

This comment has been minimized.

Copy link
Collaborator

commented Jan 4, 2019

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

This comment has been minimized.

Copy link

commented Jan 4, 2019

"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

This comment has been minimized.

Copy link
Member

commented Jan 4, 2019

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.

@Friss Friss deleted the Friss:update-webpack-dev-server branch Jan 4, 2019

@lock lock bot locked and limited conversation to collaborators Jan 9, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants
You can’t perform that action at this time.