Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
🐛 bug report: parcel does not load existing sourcemaps of pre-transformed JS assets
See original GitHub issueThis is a 🐛 bug report
General summary:
Importing/requiring a pre-built file does not load its sourcemaps.
For example, mapbox-gl-js exports a pre-packaged main which lives in node_modules/mapbox-gl/dist/mapbox-gl.js. It also contains a sourceMappingUrl //# sourceMappingURL=mapbox-gl.js.map. There is a mapbox-gl.js.map in dist/ as well.
When doing import mapboxgl from 'mapbox-gl' , parcel correctly bundles node_modules/mapbox-gl/dist/mapbox-gl.js, but does not load and re-process its sourcemap.
I haven’t gotten far with debugging it, but it seems that that file does not satisfy any of the conditions that would mark it for transformation (https://github.com/parcel-bundler/parcel/blob/master/src/transforms/babel.js#L29).
Artificially marking it for a transform (by hardcoding something like if (/mapbox-gl\.js/.test(asset.name)) return true will run the babel compiler on it, which is also not what we want.
To reproduce:
yarn add mapbox-gl
Inspect the entrypoint:
❯ jq .main node_modules/mapbox-gl/package.json
"dist/mapbox-gl.js"
Inspect the presence of the entrypoint and the map:
❯ ls node_modules/mapbox-gl/dist/
mapbox-gl-dev.js mapbox-gl.css mapbox-gl.js mapbox-gl.js.map svg
Looks like we’re pointing to the sourcemap correctly:
❯ ag "sourceMapping" node_modules/mapbox-gl/dist/mapbox-gl.js
566://# sourceMappingURL=mapbox-gl.js.map
Import the file, and package it with parcel:
// index.js
import mapbox from 'mapbox-gl`
// index.html
<html><body><script src="./index.js"></script></body></html>
❯ parcel index.html
Server running at http://localhost:64815
✨ Built in 1.88s.
Verify that the sourcemap of mapbox-gl.js does not get repackaged:
🌍 Your Environment
| Software | Version(s) |
|---|---|
| Parcel | 1.5.1 |
| Node | v8.9.3 |
| npm/Yarn | 1.3.2 |
| Operating System | Darwin |
Issue Analytics
- State:
- Created 6 years ago
- Reactions:7
- Comments:12 (1 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
This seems easy enough to do. We already have the infrastructure in place, just need to parse the existing source map url comment in the code and load it.
I am willing to re-open this issue as I have come across this problem earlier today, and after taking a look at #1349 I understood where the problem is. #1349 did not entirely solve this issue, below is an explanation as to why.
From the source code of #1349, in file
src/assets/JSAsset.js, line 26:Then later, line 114:
This would work fine if all
sourceMappingURLstatements started with//. I have recently started to work with neovis.js, a client visualization tool for Neo4j databases. Now take a look at their minifiedneovis.jsfile, line 95, column 21247:Uh-oh, looks like folks at neovis.js felt like using multiline comments (
/* */) instead of the usual//forsourceMappingURL. I started thinking that it might be a neovis.js related issue, however it turns out things work fine with webpack.After looking at the source code of parcel v2, it seems that the regexp has been corrected since v1. In file
packages/core/utils/src/sourcemap.js, line 7:It remains a problem as installing parcel with a simple
yarn add parcelstill defaults to v1. For now a temporary fix would be to upgrade to v2, but using the@nextversion of a package is not an acceptable fix, IMHO.I think this could be solved by simply copying the regexp from v2 to the v1 source code, should I file a pull request with the changes?