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.

[montogeek]

@jeremenichelli @skipjack made me a contributor so I think it would be ok to opening a PR directly from @TheLarkInn branch.

Yeah, that sounds good, problem is majority of developers don't read commits history, releases pages, releases.md, history.md or even a readme. Maybe we could find some way to link an issue or branch or something that shows what is the status of the package directly in the page, at the end the objective with this page is to conglomerate all that information in one single place.

[lencioni]

@montogeek looks great, thanks for working on this! 💃 Here are some thoughts:

• I think labeling anything where the semver range for webpack peerDep is not explicit (either missing or something like *) we should say "unknown".
• It would be great to provide some clear guidance on this page to help the maintainers of these packages clearly understand the path they need to take to go from (0) not being listed at all -> (1) being listed with "unknown" compatibility -> (2) being listed with outdated compatibility -> (3) being listed with up to date compatibility.
• I think we should get this status page up with these instructions before opening issues or PRs on packages to add or modify peerDeps. That way the benefit will be much clearer.
• It might be nice to have a separate place to list dead packages. We can figure out this later.
• I wonder if this list should be alphabetically sorted?
• It might be nice to use the semver package to give each of these packages a little green check mark or something if they are compatible with the latest webpack release. That would help people interpret the data at a glance for the most common use case.

[jeremenichelli]

We could contact all teams in Slack and see if they can help adding the peerDependency value or propose a way for the script to detect the current status of the package regarding the current webpack version. We need ideas for sure, to avoid issue spamming and to help @montogeek build the script.

[montogeek]

@jeremenichelli I already did that script, that is how I got that list: https://github.com/webpack/webpack.js.org/pull/1857/files#diff-f442a5314c6923d4650227050bd66738R35

[jeremenichelli]

@montogeek I meant the definitive version, since apparently just scrapping the peer dependencies of the packages is not enough and could case negative effects

[lencioni]

What negative effects?

I think we should stick with peerDependencies, list everything that can't be determined as "unknown" and provide clear guidance on how to take your package from "unknown" to ✅

[jeremenichelli]

Sorry maybe I misunderstodd one part of the conversation. If the list with peerDependencies satifies our needs I'm good. But I would suggest reaching out maintainers of the modules so they can update with time the package data and avoid confusion in the users.

[TheLarkInn]

Please feel free to make any changes you want. What I had was a start, by all means you can make any changes you need!! <3

…

On Mon, Feb 26, 2018 at 2:55 PM Jeremias Menichelli < ***@***.***> wrote: Sorry maybe I misunderstodd one part of the conversation. If the list with peerDependencies satifies our needs I'm good. But I would suggest reaching out maintainers of the modules so they can update with time the package data and avoid confusion in the users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1852 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQBMJD3CMz4RppH8bJJH-OiBnJxUqbSks5tYzZbgaJpZM4SR25q> .

[montogeek]

@lencioni

1. Yes, a label should be added, "Unknown" or a link to a PR or Issue with further details about the state.
2. Yes, we could add a message pointing to migration guides.
3. I think the same, but it is not completely necessary, we could start submitting issues or PR directly adding peerDependencies and clarifying that is ecosystem effort.
4. What a list dead package for you? No longer used? Incorporated into webpack? Not longer maintained?
5. Yes, that would be great. What is your idea, to add a green check if it is compatible with the latest version of webpack? I thought about adding columns for webpack 3 and webpack 4, something like:

Package	webpack 3	webpack 4
foo	✅	✅
bar	#issue	✅
baz	#PR	✅

[lencioni]

What a list dead package for you? No longer used? Incorporated into webpack? Not longer maintained?

All of the above?

add a green check if it is compatible with the latest version of webpack?

Your table looks pretty good to me