You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In debugging an issue that appeared in our builds today, I discovered that a breaking change had been introduced in version 0.7.0. Initially, I have to admit, I was a bit frustrated to discover this, and I hope that frustration doesn't come through in this suggestion.
Anyway, I understand that a semver less than 1.x.x is generally considered to be the "the wild west", where things can change with very little notice. However, I would suggest that a library of this maturity, which according to NPM is downloaded nearly 3 million times a day, should move out of the 0.x.x phase and into the more "disciplined" 1.x.x phase of development.
Thanks very much for this library, and hopefully I am not coming across ungrateful for all the hard work put into this module!
Reacted by Ryan Elian, Joshua Wiens, David Sheldrick, hexray-newbee, Haroen Viaene, Elliot Nelson and Simon Siefke
We are in the same relative boat in @webpack. There is an open CVE for the 0.6 minor version range, 0.7 resolves that issue but also drops support for NodeJS > 8 which is breaking on our end.
As stated above, sub 1.0 is considered unstable and this is what it is. None the less, from a consumers perspective, dropping Node versions ( in this case an LTS version ) is problematic.
The current options are to pin to 0.6 w/ the CVE or use 0.7 and drop support for an LTS version of Node.
I would like to propose another possible solution that would be less intrusive, a PR to resolve the CVE published as 0.6.2 which allows this project to retain a bit more semver freedom pre-stable release.
Why not just take master and publish it as 1.0.0? Is there a reason why this module with so many active downloads and after so much time is still not properly published under a major version? Both curious and would like to know if there is something we can do to help.
I think it makes sense to do some cleanup and due diligence to ensure current users of 0.5/0.6/0.7 have an upgrade path, but afterwards I think publishing a version 1.0.0 is likely.
Activity
joshwiens commentedon Apr 18, 2018
We are in the same relative boat in @webpack. There is an open CVE for the 0.6 minor version range, 0.7 resolves that issue but also drops support for NodeJS > 8 which is breaking on our end.
As stated above, sub 1.0 is considered unstable and this is what it is. None the less, from a consumers perspective, dropping Node versions ( in this case an LTS version ) is problematic.
The current options are to pin to 0.6 w/ the CVE or use 0.7 and drop support for an LTS version of Node.
I would like to propose another possible solution that would be less intrusive, a PR to resolve the CVE published as
0.6.2which allows this project to retain a bit more semver freedom pre-stable release.The CVE for reference: https://nodesecurity.io/advisories/46
Loader Issue for reference: webpack-contrib/source-map-loader#62
tromey commentedon Apr 19, 2018
I don't understand the relationship between this CVE and source-map. Could you explain it to me?
hueniverse commentedon Feb 12, 2019
Why not just take master and publish it as 1.0.0? Is there a reason why this module with so many active downloads and after so much time is still not properly published under a major version? Both curious and would like to know if there is something we can do to help.
hybrist commentedon Apr 18, 2021
I think it makes sense to do some cleanup and due diligence to ensure current users of 0.5/0.6/0.7 have an upgrade path, but afterwards I think publishing a version 1.0.0 is likely.