Access to v3 doc?

[estaub]

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.

[montogeek]

@estaub It is something missing in the official website?

[estaub]

@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.

[jderijke]

missing v3 doc too. Can a snapshot be made accessible in something like https://webpack.js.org/3?

[montogeek]

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.

[estaub]

@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.

[montogeek]

That shows the latest version, but I see your point

[wldcordeiro]

@estaub yeah the version pill is problematic and misleading because the docs are definitely 3.x but users will end up getting 4.x if they just run npm i webpack. I'd say we should have a version selector similar to something like Django or Ember

[dbkaplun]

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.

[montogeek]

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 ?

[estaub]

@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:

• Is it 3, not updated yet?
• Is it the same in both?
• Is it 4-only, and the author of the v4 content forgot (or didn't know) to preserve 3-specific guidance?

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, ...

[TheDutchCoder]

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/