-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New version 5.6.0 introduce breaking changes to the plugin interface #1837
Comments
Hmm, in the future we want to remove |
I think only having I have no idea how rare my use case is, but I am guessing its not too common. The main reason I made this bug report was to inform you of the issue, and potentially aid others having a similar usage of the package. One could argue that this change would require a major version bump to 6.0.0, since the change is not backwards compatible in my case. That is the only real issue here I think. So other than potentially a version bump I do not see any need to change anything regarding this issue :) |
Just spent around 2 hours debugging and fixing the issue. 😭 We had a high traffic tonight, the static material traffic which should be handle by the CDN flow directly to main server, even causing the monitoring to crash. IMO, There definitely should NOT be any breaking changes from version |
Current behaviour 💣
I know my situation might be quite niche but I wanted to let you know of the issue.
In the company I work for we use CRA (yes we are looking to migrate to something else). We override the react-scripts mainly to enable Module Federation. As a part of this override we need to set the publicPath in the html-webpack-plugin to the same value as the PUBLIC_URL env variable.
So until reacently our override script looked like this:
As you can see the script is setting the publicPath on the "userOptions" property of the plugin.
This has worked fine up until release 5.6.0 (that is the suspected release my react-scripts version is using ^5.5.0).
I logged the plugin using JSON.stringify and get:
... continued in expected behaviour
Expected behaviour ☀️
When I log the plugin contents before version 5.6.0 i get:
So the new version adds the "options" entry.
So I guess I would expect the interface to be the same for a semver version of 5.x.x
Reproduction Example 👾
See above its a change in the plugin interface.
Fix using 5.6.0
In my case the issue can be fixed with version 5.6.0 by simply setting the publicPath on the "options" instead of the "userOptions" entry.
Environment 🖥
Node.js v18.19.0
win32 10.0.19045
npm --version 10.2.3
wepack:
-- [email protected] +-- @pmmmwh/[email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected] |
-- [email protected] deduped+-- [email protected]
| +-- [email protected]
| |
-- [email protected] deduped |
-- [email protected] deduped+-- [email protected]
|
-- [email protected] deduped +-- [email protected]
-- [email protected]`-- [email protected] deduped
plugin:
-- [email protected]
-- [email protected]The text was updated successfully, but these errors were encountered: