-
Notifications
You must be signed in to change notification settings - Fork 71
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
please update source-map to 0.7 #34
Comments
@pravi right now impossibly, look https://github.com/mozilla/source-map/blob/master/CHANGELOG.md#070
|
Relevant downstream issue firefox-devtools/debugger#5598 |
Do you think webpack-sources could be updated in a way that supports both the old and new versions of source-map? That would allow folks running Node 8+ to get the performance improvements without hurting folks on older Node. Thoughts? |
@lencioni we work on this mozilla/source-map#326 (comment), can't do here, it should be solved in |
@evilebottnawi I'm not sure I understand why this can't be resolved here, can you explain in a little more detail? As far as the API is concerned, it seems that the main change is that source-map is now async instead of synchronous. Could we make this work by doing the following?
This would give consumers the option to update to a newer version of source-map, if they are on a new enough version of Node, or continue using the much slower 0.6 if they are on an older version of Node. Or, is there something else missing that I don't understand? |
I think this is the issue here because something like An option I have been thinking is either
"postinstall": sh -c \"if [ node -p -e 'process.version > 8' ] then; yarn install source-map@^0.7.1 else yarn install source-map@^0.6.1 fi\"
require('source-map/package.json').version and have conditional code that way @evilebottnawi I think this is related to our discussion on the uglify-js plugin webpack-contrib/uglifyjs-webpack-plugin#248 What are your thoughts on those 3 ideas? |
@mlavina i think 2 point is looks good, let's do it first in plugin, example uglify/terser and then implement here, feel free to PR. Also some people use npm, better create |
What about having an intermediate package - e.g. It can have a peer dependency on |
Yeah that's the part that we need to figure out At this point Node 6 is almost out of maintenance mode in April 2019 and I think at that point we can probably justify the breaking change to drop Node 6 support. If that's the case I am somewhat more inclined to wait then submit my proposed changes. |
What's the status of updating FYI @TheLarkInn - the performance fix in mozilla/source-map#308 which never made it to the 0.6.x branch, but only to the new async/WASM 0.7.x branch of As mentioned in mozilla/source-map#370 (comment) I applied the perf fix via I will be trying upgrading our main build to Webpack 4 later this week, which we previously couldn't do due to a combo of perf & memory pressure which I now suspect was due to this issue. Also, I notice that even the Webpack 5 branch is still using |
In todo for webpack@5 |
Sorry, but the In my opinion using WASM is not really needed for good performance in source-map. Or at least it's not worth the trade-off of additional complexity (async, managing wasm buffer initialization). I really thinking about creating my own version of |
I think will be great to look on benchmarks, maybe we can open an issue about Issue: mozilla/source-map#331 |
To be honest I'm less concerned about the WASM etc stuff that comes with the newer versions of Maybe it would be enough as a starting point to fork |
I just noticed 7rulnik/source-map-sync/pull/1 (source-map-sync on npm), which modifies source-map 0.8 to expose a synchronous API, by initializing the wasm module with The downside of this approach is that it won't work in browsers, since they apparently have a 4kb size limit for the synchronous initialization API. I know there are some projects that use Webpack in the browser too, but perhaps it could be configured somehow that on Node, Webpack would use the source-map-sync library or something else like it. I tried it on our project with yarn resolutions "resolutions": {
"**/source-map": "npm:source-map-sync@0.8.0-beta.2"
} and it cut about 15-20% of our total production build time. |
Yep, but I prefer source-map-js |
Major version 3 of webpack-sources is now super fast, and dependency-free. (not yet fully bug-free, but I'm working on that). |
With source-map 0.7, two tests are failing.
The text was updated successfully, but these errors were encountered: