Open estaub opened 6 years ago
@estaub It is something missing in the official website?
@montogeek I don't know what the current state is. AFAICT, most of the changes needed for 4 aren't there yet, which is one of the things I'm waiting for before switching.
It will be very difficult to maintain doc that works well for both, though; everything different will need to be labeled 3-only or 4-only somehow, e.g. CommonsChunkPlugin, UglifyjsWebpackPlugin, the new optimization config, etc. People will forget to preserve 3-only content, and it will make for awkward and error-prone reading. I'd think it would be easier to just serve two versions of the doc as a whole than to worry about any of this.
missing v3 doc too. Can a snapshot be made accessible in something like https://webpack.js.org/3?
Everything in the website is for webpack 3, AFAIK nothing has been deleted. CommonsChunkPlugin does not longer exists in webpack 4, but the page is available (https://webpack.js.org/plugins/commons-chunk-plugin/), the plan is to add a deprecation warning linking to its replacement, never remove it.
Making a snapshot of the docs would be good, but I am afraid it would require a lot of work since it does not exist.
@montogeek The black-and-blue chip in the upper corner of the doc saying "webpack v4.0.1" leads readers (like me) to think that it at least attempts to doc v4.
That shows the latest version, but I see your point
I second having a version selector. I frequently look for nonexistent old docs and am forced to do git blame
to find the right version, and read source code itself.
Thinking more about this I am not sure if it is worth to have an entire version of the website for each version, although it is a major release, not a lot of things changed, there is 113 pages of documentation from which approximately only 25 (22%) would need an update for webpack 4.
What you think about this @TheDutchCoder @jeremenichelli ?
@montogeek At the risk of seeming snarky... why do folks do all that forking with git? Most of each of the forks are all the same.
Like forking, the advantage to having separate versions is complete unambiguity. Otherwise, for any page that has no reference to 3 or 4, the reader is left wondering:
I'm ignorant of the devilish details, but I'd be surprised if, at the end of the day, it's easier to cover 3 and 4 well in the same doc than it is to publish two versions. It isn't of only temporary value, either; there will be a 5, 6, ...
I'm usually a proponent of having versioned docs. It might feel a bit verbose, but I think it's critical to have at the very least major versions split out in the docs as they usually differ significantly.
We could opt for latest release of each major version?
We'd have to find a way to (re)structure this on the website, but a simple dropdown should suffice and maybe adding versioned sub-directories in the project (src/content/v3
).
We would need some input from other people on this though, but I'm all for it!
For example, Vue.js has a version selector for the docs: https://vuejs.org/v2/api/
I am in as well!
@TheDutchCoder, thinking of what @montogeek said: since there are only less than 1/4 of the documentation need v4 update -- may be we can have version section in the same page, place V4 at the top section, which follow by V3 section, that way we can have this up quickly without having to add a drop down or restructure the entire website.
@montogeek magic comments are not the same as between v3.x.x and v4.x.x (ie no lazy-once in v3)
Isn't ironic that for a build system that seems to do very well in fingerprinting output assets fails in applying this to it's own documentation.
entry: {
docs: '**/*.html'
},
output: {
path: '[pkg.version.major].[pkg.version.minor]/[name].[ext]'
}
Something that really needs to be thought about.
Lodash does a great job of providing access to multiple versions of their docs both via url and through a UI control that lets you easily switch versions. This should be the standard way of doing things for any documentation.
Example. https://lodash.com/docs/4.17.5
This is really, really confusing at the moment. I am required to use v3, and it's not stated anywhere that the docs for v4 are largely compatible with the docs for v3. Keeping snapshots of old docs for a project as large as webpack would be a huge plus.
Please use https://webpack.js.org/v3/ for webpack 3 docs.
@montogeek that link is perfect -- thanks!
Are there plans to add a version selector to the docs? (right now it's not really discoverable)
Great! Little remark: the doc at https://webpack.js.org/v3/ still indicates it's v4.4.1.
If you tag the the v3 releases you should be able to reference the tag with the shields.io badge:
This doesn't seem to work now: https://webpack.js.org/v3/
For the love of God pls provide v3 doc.
Im crying for it...
@kinyat i cloned it locally: https://github.com/webpack/webpack.js.org/issues/1961#issuecomment-378963332
@kinyat Try again please
@montogeek https://webpack.js.org/v3/ is still 404, I'm afraid.
@montogeek It's up!
@estaub I integrated into our deploy script #1992
@estaub It is down (404) again πππππ Nvm, I will just follow @ApolloTang comment
@montogeek, the URL you provided still (or again) returns 404. Edit: Sorry, I didn't find this explicit enough. @ApolloTang explains here how to clone and run v3 docs locally, which may be the only way now to see them.
https://webpack.js.org/v3/ is still 404 for me. I am going to be on v3 for a while, so easy access to the documentation would be a big help.
It would definitely be really helpful having the old docs hosted someplace
Hi Guys, we are thinking to create a sub-domain strategy for versions and probably add a dropdown switch to walk between the versions on the website frontend. This would result at first in v3.webpack.js.org and so on.
There is no ETA for this feature right now as we are still trying to agree terms and requirements with hosting provider.
Yet again you manage to surpass my expectations of having the most shitty documentation website while having all the resources in the world to do this right.
I come here because I struggle to find the v3 documentation website only to find out that people are already talking about Webpack v5 while your documentation website has been in shambles since day one.
What a joke.
@stephan-v If you think you are solving anything by talking like that to people who are donating their spare time for you to have a free tool, you are sorely mistaken. Literally any minute I spend on this, including writing this answer, is spare time taken away from me being a parent to my daughter and a husband to my wife. Tell me how this equals "all the resources in the world" please?
Don't know perhaps the 400k in funding Webpack receives yearly? That is even besides contributors like yourself.
@EugeneHlushko that gameplan sounds perfect. Hoping you guys get a solid deal from your hosting provider.
@stephan-v let's try to keep this conversation civil and constructive. The unfortunate reality is that for even the most popular open source projects like webpack, 95-99% of contributor's time is voluntary and unpaid. I sincerely wish this weren't the case, but that's how open source works for the time being.
@Munter, I wish more people would lay out the realities of OSS projects like this. Also, while I can still get lost in the complexity (and power) of Webpack and its configs, I think the docs have improved immensely since I first used it.
FYI, this still appears to work (be sure to get the correct tag). The version badge appears to be querying for latest, so it's misleading, but it looks like the old docs are faithfully presented in my local.
Another way is to look up the actual source code, like the default options:
https://github.com/webpack/webpack/blob/master/lib/WebpackOptionsDefaulter.js#L73-L93
Itβs on the Internet Archive, too: https://web.archive.org/web/20180216190554/https://webpack.js.org/concepts/
All I have to say is: and https://api.jquery.com/category/version/1.0/. Doh!
@moos So we are comparing asset bundlers to JavaScript libraries now?
The unfortunate reality is that for even the most popular open source projects like webpack, 95-99% of contributor's time is voluntary and unpaid. I sincerely wish this weren't the case, but that's how open source works for the time being.
If anyone wants to see this fixed, pay someone to do it: https://www.bountysource.com/
Here you can find a zip
to download the guides. StackOverFlow
mode
is not v4. splitChunks
isn't either.
Decided to host it for my own help (tag v3.11.0). Feel free to use https://webpack-v3.jsx.app
For Mainland Chinese developers https://webpack-3.cdn.bcebos.com/
This is official tagged doc for v3.11.0: https://github.com/webpack/webpack.js.org/tree/v3.11.0/src/content/configuration
@bendtherules for the president!
While we wait for all the V4 plugins and issues and docs to settle down, folks still need to get work done with V3. It would be nice to have access to the docs.