General - Ecosystem Status Page

[webpack-bot]

On the Twittersphere, I recently tweeted:

One of the more painful aspects of the previous couple of #webpack major version releases was waiting for all the related packages to publish compatible versions.

Is there a webpack ecosystem status page to track compatibility progress for these events?

People seem to think this would be useful as a page in the webpack documentation. I think maybe having a table that lists each plugin or loader or whatever and how ready it is for any given webpack release would be awesome. I think relevant statuses might be unstarted, in progress, merged, and published.

Keeping this list up to date should be a community effort and might be a good, low-cost way to encourage folks to get involved and contribute to webpack documentation.

---

This issue was moved from webpack/webpack#6560 by @sokra. Orginal issue was by @lencioni.

[skipjack]

I think maybe creating a page at ./src/content/status.md (or ecosystem-status.md) could work. The only thing to keep in mind is that this will take some serious effort to keep up to date. It might be a good opportunity for automation, e.g. reading peerDependencies in the latest versions of webpack-contrib packages and seeing which webpack version they support.

I'm going to leave this decision to @jeremenichelli as he will be taking over the lead role on the repo soon. @lencioni if we did decide to include this page and agreed on an approach, would you be willing to start a PR for it?

[jeremenichelli]

I'm a little hesitant about this because of the maintainance a file like this would require. If we are not automating the generation of the file by scrapping the peerDependencies required like @skipjack suggested there's a high chance the file gets easily unsync and out to date, not serving to its purpose.

[TheLarkInn]

I started a bit on something like this. Although I agree with @jeremenichelli I think depending on something like peerDependencies would be the best way. Here's the work I started for it. 1df6f60

[jeremenichelli]

That's a really good start @TheLarkInn, will see if I have time before v4 release, if not I can get into it after the big day.

[montogeek]

I am working on it, from @skipjack idea, there are some packages that does not specify its peerDependencies, so first we should updates those packages:

[ 
  'json-loader',
  'raw-loader',
  'css-loader',
  'style-loader',
  'script-loader',
  'bundle-loader',
  'i18n-loader',
  'json5-loader',
  'imports-loader',
  'exports-loader',
  'coverjs-loader',
  'node-loader',
  'coffee-redux-loader',
  'transform-loader',
  'html-loader',
  'source-map-loader',
  'react-proxy-loader',
  'null-loader',
  'multi-loader',
  'yaml-frontmatter-loader',
  'svg-inline-loader',
  'restyle-loader',
  'gzip-loader',
  'copy-webpack-plugin'
]

Also, some other packages specify peerDependencies but not webpack in it:
[ 'coffee-loader', 'url-loader', 'jshint-loader', 'mocha-loader' ]

I could go on each of those packages and start adding it

[montogeek]

This is how it looks at this moment:

[jeremenichelli]

Looks great @montogeek, are you working inside a PR? Throw the link reference here, and tell us when you are ready so we can review it.

[jeremenichelli]

We should ignore packages with no peerDependencies declared or put something like unkown webpack compat version: check out the package repository

[montogeek]

@jeremenichelli There is not PR, I am afraid to open one since it was @TheLarkInn work.
Branch is https://github.com/webpack/webpack.js.org/tree/feature/compatibility-page

@jeremenichelli When the user goes to the package repository, What would they find different from this page?

[jeremenichelli]

Well first, not at all @montogeek don't be afraid. Sean and everyone will appreciate you are working on it. Just create a branch from his and whenever you have something in place submit a Pull Request explaining its content. No one will have a negative comment or an objection about an intend of contribution as long as you communicate somehow you are working on it 😉

Second, they will have the README and history of commits which should be enough information to know if the module has been updated to v4, if not they can open an issue.