Skip to content
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

Breaking change. #5837

Closed
antoniodesenvolvedor opened this issue Jun 11, 2024 · 5 comments
Closed

Breaking change. #5837

antoniodesenvolvedor opened this issue Jun 11, 2024 · 5 comments

Comments

@antoniodesenvolvedor
Copy link

The last release is considered a breaking change since default input was changed, following semver the new version should be 4.0.0.

I was using a pipeline with grunt and grunt-contrib-uglify, but grunt-contrib-uglify requires "uglify-js": "^3.13.3" which allows only minor non breaking changes, now it breaks any pipeline that relies upon the default value and has code not compliant with "use strict".

Previous uglify-js version 3.17.4

- `module` (default: `false`) — set to `true` if you wish to process input as
  ES module, i.e. implicit `"use strict";` and support for top-level `await`,
  alongside with `toplevel` enabled.

New uglify-js version 3.18.0

- `module` (default: `true`) — process input as ES module, i.e. implicit
  `"use strict";` and support for top-level `await`. When explicitly specified,
  also enables `toplevel`.

Reference:
v3.17.4...v3.18.0#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L533-L536

I will fix my pipeline by downgrading to [email protected]

@alexlamsl
Copy link
Collaborator

Thanks for the report, but that's not how version numbering works in this project.

@std4453
Copy link

std4453 commented Jun 14, 2024

@alexlamsl Sorry for the disturbance but I do think that a change of default configuration IS a breaking change.

Such is agreed on in this StackExchange thread:

I would consider any change that forces a user to modify their code/configuration as a result to be a breaking change.

And also by the Microsoft dotnet contributors in their Breaking Change Rules:

Disallowed

Changing the default value for a property, field or parameter (either via an overload or default value)

Currently this change is already causing problems in our project, forcing us to lock version for uglify-js or modify our configuration, which is exactly what breaking change is about - it breaks things so that it should NOT be auto-upgraded.

I would suggest re-opening this issue, publishing a new 3.8.1 version reverting this change, and new changes should start with 4.0.0.

@alexlamsl
Copy link
Collaborator

I do not work for or sponsored by any of such entities you've mentioned, so I don't see why I should heed any of their rules and/or opinions.

@std4453
Copy link

std4453 commented Jun 14, 2024

@alexlamsl It’s about basic understanding of semantic versioning. Most packages on npm obey the rules of semantic versioning, and it’s the assumption of package managers like npm and yarn, in order that the whole system can work together. Currently this change in uglify-js is breaking the system, which is why it should be corrected.

@antoniodesenvolvedor
Copy link
Author

I do not work for or sponsored by any of such entities you've mentioned, so I don't see why I should heed any of their rules and/or opinions.

@alexlamsl we should follow this standard to make it much easier and safer to use newer versions of UglifyJS without worrying about "hidden" breaking changes.

stdavis added a commit to agrc/electrofishing-query that referenced this issue Jul 9, 2024
Unfortunately, UglifyJS does not follow semantic release standards. And I couldn't figure out a way to pass the module parameter via the grunt task.

mishoo/UglifyJS#5837
stdavis added a commit to agrc/locate that referenced this issue Jul 15, 2024
Unfortunately, UglifyJS does not follow semantic release standards. And I couldn't figure out a way to pass the module parameter via the grunt task.

mishoo/UglifyJS#5837
stdavis added a commit to agrc/deq-spills that referenced this issue Aug 8, 2024
stdavis added a commit to agrc/raster that referenced this issue Oct 3, 2024
stdavis added a commit to agrc/locate that referenced this issue Oct 4, 2024
stdavis added a commit to agrc/electrofishing-query that referenced this issue Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants