Comment by btown | Hacker News Reader

Comment by btown | Hacker News Reader

IMO, Webpack (and React Router [0]) have been in this weird and honestly toxic place, where there was very little regard held for backwards compatibility and gradual deprecation by the core teams at first, so businesses with larger apps became marooned on previous versions as soon as the first major version change... thereby not contributing their expertise and bug reports (they spent that time fighting against the lack of documentation), and thereby making it even more difficult for the core teams to get feedback on people's real-world migration woes.

It's fair to say that there were problems in the earlier APIs, but if that's the case, make changes gradually, even create an RFP process, tease/market your API change proposals to get feedback from people who might say "this is not something we can adopt easily, but you could add this param for backwards compatibility." It'll take longer to get to an API that feels "perfect," but it makes for a stronger culture.

[0] https://github.com/ReactTraining/react-router/blob/master/pa...

I remember reading of Babel maintainers releasing betas and asking for feedback but not many helped; most just came to complain after the release.

Webpack 4 has been in beta for a while but not enough people tested it on real projects, evidently.

Well, when there isn't enough documentation, yet so many breaking changes are introduced, then I don't really see how exactly people should have managed to get it to work to test it on real projects.

You're not wrong; documentation especially for migrating is poor. Having to google one error at a time is annoying.

Yep - either introduce redesigned APIs with deprecation warnings in minor releases, or at least build codemods. Make it so that if you fix everything deprecated, you can upgrade with minimal effort. React itself does this, for instance.

> Webpack 4 has been in beta for a while

Perhaps the naming is sending the wrong message? "Beta" sounds incomplete and subject to change; I certainly don't make a habit of introducing betas to serious projects unless there's something in them I'm desperate for.

An extended period of Release Candidate versions could give end users more confidence in adoption. This naming implies that the product is finalised and will be released as-is barring serious bugs. It's a small thing, but maybe giving end users the feeling of being early adopters rather than beta testers could increase uptake in this final critical stage.

Or React's way of avoiding major version cliffs seems to have grown out of this problem.

https://reactjs.org/blog/2016/02/19/new-versioning-scheme.ht... (skip to the major versions and avoiding cliffs part)

Correct me if I'm misunderstanding the beta process in the javascript ecosystem, but Webpack v4 went into beta on Jan 25 [1] and removed the beta label on Feb 25 [2]. That's not "a while". While I don't want to detract from the work of maintainers—webpack is a great tool that's central to the workflow of thousands—the lack of documentation coupled with an extremely brief beta period gives most of us the impression of a haphazard, half-baked release that we just aren't going to trust for at least several more point releases.

[1] https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d2...

[2] https://medium.com/webpack/webpack-4-released-today-6cdb9947...

Here [0] is a react-router alternative, if you don't need the fancy stuff.

https://medium.com/@daveford/react-router-alternative-switch...

Note that react router 4 does support passing props down explicitly using the "render" parameter instead of component parameter. This was my biggest gripe with previous versions where you had to resort to cloneElement, which is a pain.

Reply on news.ycombinator.com