search

parcel-bundler / parcel

The zero configuration build tool for the web. 📦🚀
https://parceljs.org
MIT License
43.53k stars 2.27k forks source link

Inline bundles are missing source maps #6225

Open Jezternz opened 3 years ago

Jezternz commented 3 years ago

🐛 bug report

It appears that even with explicit sourceMaps true or {inlineSources: true, inline: true}, no inline sourcemap is generated.

🎛 Configuration (.babelrc, package.json, cli command)

packages.json

{
  "name": "parcelv2-example",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "start": "rm -rf ./dist/ && parcel build ./src/index.html"
  },
  "author": "",
  "targets": {
    "default": {
      "context": "browser",
      "sourceMap": true,
      "engines": {
        "browsers": [
          "> 0.5%",
          "not dead"
        ]
      }
    }
  },
  "dependencies": {
    "parcel": "^2.0.0-beta.2"
  }
}

index.htm

<!DOCTYPE HTML>
<html>
<body>
    <script type="module">
       import A from "./a.js"; 
       A("some long text");
     </script>
</body>
</html>

a.js

const A = async long_name => await new Promise(r => setTimeout(() => r(long_name), 100));
export default A;

output index.html (see js is correctly minified, but incorrectly no sourcemap is provided)

<!DOCTYPE HTML><html><body> <script type="module">(async e=>{await new Promise((t=>setTimeout((()=>t(e)),100)))})("some long text");</script> </body></html>

🤔 Expected Behavior

Expect to see an inline sourcemap appended to the <script type="module">.

😯 Current Behavior

No inline sourcemap there.

🔦 Context

Developing a small app, that should be a single html file, but also needs to be debuggable so requires inline sourcemaps. Used example here as base.

💻 Code Sample

Also attached parcelv2-sourcemap-example.zip containing the same code as above, you can extract and run "npm start on".

🌍 Your Environment

Software Version(s)
Parcel 2.0.0-beta.2
Node 14.16.0
Operating System Win10
mischnic commented 3 years ago

Sourcemaps were disabled for inline bundles (<script>.....</script>) on purpose: https://github.com/parcel-bundler/parcel/pull/4859

Jezternz commented 3 years ago

@DeMoorJasper @mischnic Is there anyway I can convince you to reconsider retaining the functionality even though it does add some complexity, possibly behind a flag in the sourcemaps config object.

The best arguments I can think of are:

I realise this is not the main use case for parcel, but have found parcel uniquely good at solving problems around bundling so would like to keep using it. (My use case is basically the need to be able to have a single all contained html file that can be generated and sent out, at least for my purposes even having an external sourcemap for inline js would be better then none)

I understand this is an OS project so you have to choose where you spend your limited time - thanks for parcel it is awesome.

mischnic commented 3 years ago

external sourcemap for inline js

Not sure how complicated that would be, but that is the only solution that doesn't have the massive downsides of inline sourcemaps in inline bundles.

Jezternz commented 3 years ago

Just to make sure I understand correctly the downsides are primarily focused around performance? (Extra time to generate when parcel runs and extra bytes to download and parse when the browser runs?)

mischnic commented 3 years ago

Extra time to generate when parcel runs

It doesn't make a difference for the build time

extra bytes to download and parse when the browser runs

Exactly

Jezternz commented 3 years ago

And I guess the primary obstacle to putting this behind a flag is the added complexity / maintenance etc?

mischnic commented 3 years ago

The general problem is that inline bundles (= what becomes the content of the <script> tag) themselves don't have a file path (because they aren't written to disk). So the usual method of "create a file *.map next to the bundle" doesn't work in this case.

Jezternz commented 3 years ago

I had thought that because Parcel 1 handled it well there was a good chance Parcel 2 would - though I understand there are other considerations. At least for my unusual case I may need to revert to Parcel 1 until I work out how to refactor around these considerations - thanks for the replies.