Better support React 16.3.0 #4090
Conversation
package.json
Outdated
| @@ -77,7 +77,7 @@ | |||
| "fresh": "0.5.2", | |||
| "friendly-errors-webpack-plugin": "1.6.1", | |||
| "glob": "7.1.2", | |||
| "hoist-non-react-statics": "2.3.1", | |||
| "hoist-non-react-statics": "^2.5.0", | |||
There was a problem hiding this comment.
@timneutkens Next.js seems to be using a yarn.lock. Why do you want to lock the versions? The larger the scope is, the less likely a package will be duplicated on user-side (smaller client bundle, faster yarn installation).
There was a problem hiding this comment.
yarn.lock doesn't work for published packages. We've had many cases where Next / other ZEIT projects broke because a faulty version was released, eg react-hot-loader. By locking we're always very sure the supplied versions work perfectly with Next (thanks to the tests).
There was a problem hiding this comment.
I've updated the PR and merged 👍
There was a problem hiding this comment.
OK thanks. It's definitely not the tradeoff I would have chosen. This solution isn't systematic. People depends on a bunch of other dependencies. Even if they don't experience broken releases from next, they will from other dependencies. So, either they don't care about it or they will solve the problem with yarn.lock or package.lock. Either way, libraries authors can ignore the problem. I would rather not harm the majority for a minority of the user base.
Anyway, I understand the motivation. I will stick to the React 16.3.0 thing :).
|
Thank you for the quick review! I was shopping outside. |
mridgway/hoist-non-react-statics#43