What versions of Webpacker/Shakapacker to support going forward?
As brought up in #1198, we probably shouldn't support all versions of webpacker/shakapacker.
Should we require a recent version of Shakapacker?
This would be much easier to support.
Does anybody have any opinions?
Besides a lot of test helpers, these seem to be the main non-test areas:
https://github.com/reactjs/react-rails/blob/f8148d57a6d96b27bddfaef9f9bf26e233b27bd6/lib/react/server_rendering/bundle_renderer.rb#L3
https://github.com/reactjs/react-rails/blob/f8148d57a6/lib/react/server_rendering/webpacker_manifest_container.rb
We already have the asset_container_class API. I wonder if we ought to separate the current WebpackerManifestContainer class into different files (for each major version) and provide them but stop doing integrated testing for them. I think that would be a happy middleground--folks can continue to easily maintain these manifests themselves by creating their own as long as meets the API requirements (which we ought to more clearly specify anyhow so that we can support other systems like jsbundling-rails) while maintenance for this lib gets a fair bit easier.
This also better enabled Shakapacker to continue to make improvements while maintaining Webpacker 5 support for a while.
@HarrisonB sounds like a good idea. Can you throw together a PR and I'll arrange a review ASAP.
@hibachrach, Do you have availability next week to work on this issue?
Let's have 2.7 have a good example with Shakapacker v6.x. Certainly, Webpacker can get configured with 5.x. That support can be left to documentation.
@justin808 Then I add this issue to Milestone 2.7
In version 2.7:
- Webpacker 5.x works fine
- Shakapacker 6.x works except with SSR
In version 3:
- Webpacker support is dropped
- Shakapacker 6 and 7 work fine
If we need anything special to do here, let's list and prioritize; otherwise, if the issue is finalized, we can close it.
CC: @justin808 @Judahmeek