Parcel: Feature request: source map support

Created on 7 Dec 2017  路  32Comments  路  Source: parcel-bundler/parcel

It would be great if parcel managed source maps.

Feature

Most helpful comment

Would also be good that I didn't have to discover this land mine. Maybe point it out on the main site.

All 32 comments

Would we only need source maps for JavaScript files?

Sourcemaps for all types (i.e. css) seem nice.

There are many problems with source maps as they exist currently. I haven't yet found a solution that works well anywhere, so open to suggestions here.

Problems I have found:

  • They are very slow to generate.
  • They are very slow to load in browsers.
  • They don't really help with debugging - variables are still potentially renamed in the debugger. You still end up looking at the compiled source anyway. They basically only help with stack traces.

That being said, I would love to be proven wrong here!

I mostly agree, but I think that something along the lines of webpack's cheap-source-map devtool offers a good compromise.

  • It's faster than standard source maps
  • Shows the compiled source
  • Helps browsers with stack traces, remap breakpoints after a bundle is rebuilt, and supports cmd+p for finding code by file name.

I've been only聽been using parcel for a couple days and have groaned more than a couple times because my breakpoints got all jumbled up, or because I tried to use cmd+p and thought "am I not importing that module?".

I've found source maps invaluable in debugging hairy stack traces.

Re. compile speed: The impact on code generation and asset transformation can be fairly large as the output might double size. However, with parcel's asset cache that should be a one-time cost for most files. The other impact is bundling, which I think means concatenating the input source maps and seems cheap enough based on my read of the source map spec (https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#).

@jasonLaster You were talking about some improvements to source maps the other day. Is there any work you can point to?

The facebook metro bundler team just extracted their source map generator into a separate module https://npmjs.com/metro-source-map thanks to @cpojer. Here's an article about how it is works https://medium.com/@david.aurelio/medium-fast-source-map-generation-for-react-native-ea5549007c18

Perhaps we can use that?

They don't really help with debugging - variables are still potentially renamed in the debugger. You still end up looking at the compiled source anyway. They basically only help with stack traces.

In production, "only the stack trace" can be incredibly valuable when you're unsure what's happening!

Unfortunately the Facebook library is licensed under BSD+PATENTS. I've asked @cpojer to look into getting that relicensed so we can use it, but no promises.

This process will likely take a while.

e.g Brunch is very similiar to parcel and has source map support builtin and it's really fast. Perhaps it can help by searching for a solution. In my opinion sourcemap support is essential to provide a great dev experience. If you compile single-file components ... and your debugger jumps into the glory it's frustrating馃拑

I have to agree on this one, I would like to help but my area of experise doesn't really go into how all these tools work internally.

Yes, the variables when it comes to Javascript do get renamed which can be frustrating but you can still step through; and chrome (the new FF seems a little iffy for me right now) can handle the scope variables in both the source view tooltips and the tree view. Really the only areas where it's lacking are the console and watch panels, after a while you learn workarounds for those too.

Then you have CSS source maps where you have none of these problems.

The main thing is actually stack traces, error logs and stepping through, without those three things I would rather wrestle with webpack for a couple of hours and spend a few hours hear and there helping my team out with thier requests.

If speed for creating sourcemaps is an issue, I recommend that sourcemap creation is optional (with default value off/false), that way the performance with current bundling processes should stay the same but if sourcemaps are needed then they could be turned on.

sourcemaps and stack tracing are essential to any professional js developer.

if you are concerned about performance then make it optional, but I know its a deal breaker for a lot of dev teams. It would be the main reason my team wont use it.

It's the main reason I've stopped using Parcel

I'll be on the lookout for sourcemap support. Until then, unusable.

If someone wants to look into implementing this, feel free. Since this is a larger feature, I think the best way to go about it would be in three steps, which could be tackled by different people:

  1. Do some research. Look at what other bundlers use (e.g. webpack, browserify, brunch, etc.). I know webpack has a million modes for these too. Not sure the tradeoffs there. Report back here.
  2. Come up with an implementation plan. Perhaps we start with only JS source maps first. How do they get combined? How do we keep things fast? etc.
  3. Implement the plan and write tests.

Thanks!!

Hmmm, this might actually be something I have experience with. I'll see what i can do.

I'm having a look as well. From what I can see, the most obvious course of action is to utilize the source maps babel already has support for. From what I can see it's literally an option you pass to it. node-sass also supports them and I'm guessing typescript and coffee script too.

It's just a question of making the parcel API nice and sleek and implementing it in such a way that other providers in the future can leverage it.

yep, babel (and others) generating source maps isn't a problem. the work will be on combining the source maps together in the JSPackager.

Would also be good that I didn't have to discover this land mine. Maybe point it out on the main site.

I was impressed by Parcel and will be waiting for source map support.

Here is what I currently have using webpack:

  • write modules in TypeScript
  • bundle as UMD and enable source map
  • publish the bundled JS and source map to npm
  • when using the library, enable source-map-loader, we can debug and trace into the original TypeScript source

I can help test it out in my library once it is developed.

Why is it closed? Is the feature implemented or rejected?

It was a duplicate, no need to make an issue if there already is one @ivangretsky Sourcemaps support should be in parcel really soon, feel free to check out #506 to test it out

Seems like it's getting close to be done. Awesome!

I'm sorry I couldn't contrib to this, but man I'm excited about this going live.

Going to use it on my next production site.

@enrichit so SASS/CSS source maps are working already?

Looks like our performance concerns just solved themselves!!

https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/

I added this config to .sassrc

{
"sourceMap": true,
"sourceMapEmbed": true
}

That then generates an embedded sourcemap in the generated CSS file. However, the sourcemap doesn't actually work within Chrome. It shows "stdin" and doesn't actually map, I'm assuming because of the JavaScript import.

Is there some way around that?

@allenmackley I recommend making a new issue

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Niggler picture Niggler  路  3Comments

philipodev picture philipodev  路  3Comments

466023746 picture 466023746  路  3Comments

devongovett picture devongovett  路  3Comments

oliger picture oliger  路  3Comments