Development server inexplicably strips type="module" from <script> tag #9716

gcleaves · 2024-05-15T06:12:10Z

🐛 bug report

Development server inexplicably strips type="module" from <script> tag, breaking the page. The normal build process does not do that.

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

No config.

Input HTML:

<html lang="en">
  <head>
    <meta charset="utf-8"/>
    <title>My First Parcel App</title>
    <script src="https://unpkg.com/petite-vue" defer init></script>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@shoelace-style/[email protected]/cdn/themes/light.css" />
    <script type="module" src="https://cdn.jsdelivr.net/npm/@shoelace-style/[email protected]/cdn/shoelace-autoloader.js"></script>

    <style>
        #graph {
          border: 1px solid #e0e0e0;
          width: 100%;
          height: 99%;
        }
      </style>
  </head>
  <body>
    <div v-scope="{ count: 0 }">
      {{ count }}
      <sl-button @click="count++">inc</sl-button>
    </div>
    <div id="graph"></div>
    <sl-drawer label="Drawer" class="drawer-overview">
      Lorem ipsum dolor sit amet, consectetur adipiscing elit.
      <sl-button slot="footer" variant="primary">Close</sl-button>
    </sl-drawer>
    
  </body>
</html>

🤔 Expected Behavior

Don't remove type=module

😯 Current Behavior

type=module is removed from the script tag in development server build only.

💁 Possible Solution

🔦 Context

Can't leverage dev server

💻 Code Sample

npx parcel --no-cache app/index.html

🌍 Your Environment

Mac OS

Software	Version(s)
Parcel	2.12.0
Node	v21.7.2
npm/Yarn	npm
Operating System	Mac OS

gcleaves · 2024-05-16T14:51:38Z

Further to this, parcel watch behaves the same way, breaking the app, while parcel build works correctly.

josewal · 2024-07-26T10:25:36Z

I am also affected by this, any workarounds?

devongovett · 2024-07-26T14:27:36Z

In development we don't use esm, so this is intentional. What is broken about it for you?

LoganDark · 2024-09-03T00:08:36Z

In development we don't use esm, so this is intentional.

What? Is that really true? Development should use ESM so I don't have to build the whole app at once... manual bundle splitting is the worst, and also impossible right now because:

Uncaught SyntaxError: await is only valid in async functions and the top level bodies of modules

Is there any way to force the dev server to use ESM properly?

devongovett · 2024-09-03T12:58:12Z

It shouldn't matter. ESM is just a syntax. What parcel outputs is an implementation detail that shouldn't affect the behavior of your source code.

Development should use ESM so I don't have to build the whole app at once

I don't understand this. That has nothing to do with ESM output.

LoganDark · 2024-09-03T16:28:55Z

It shouldn't matter. ESM is just a syntax. What parcel outputs is an implementation detail that shouldn't affect the behavior of your source code.

Development should use ESM so I don't have to build the whole app at once

I don't understand this. That has nothing to do with ESM output.

It matters when Parcel has to rebuild the bundle every time I change any module. Because the app can't even start to load until the entire bundle is rebuilt, because Parcel has to come up with a single file that contains every module. Hot reload works once, but if you change a file multiple times in a row, then the other changes have to wait for the first entire bundle rebuild to complete. It's super slow and annoying.

devongovett · 2024-09-03T22:35:45Z

The ESM format does not affect whether you bundle or don't bundle. Those are separate concerns. You can bundle both ESM and non-ESM or not bundle both ESM and non-ESM. Switching to type=module does not make it non-bundled.

Parcel delivers HMR updates before packaging finishes via a websocket, so it should update quickly regardless what module format you use.

If you don't want a bundler at all and just want an ESM dev server then I'd suggest a different tool. Parcel is a bundler and will continue to be.

LoganDark · 2024-09-03T22:43:07Z

The ESM format does not affect whether you bundle or don't bundle. Those are separate concerns. You can bundle both ESM and non-ESM or not bundle both ESM and non-ESM. Switching to type=module does not make it non-bundled.

OK, thanks for the clarification.

Parcel delivers HMR updates before packaging finishes via a websocket, so it should update quickly regardless what module format you use.

This is (partially) incorrect.

If you make one edit, then the HMR update is indeed instantaneous.

However, if you make another edit before the bundle has finished fully rebuilding, then your edit won't be applied until the first update has finished rebuilding the entire bundle.

Our app requires almost a minute to rebuild the whole bundle, so this really hurts.

I don't want to wait for our huge bundle to compile just to iterate rapidly on a single module. :/

I think this would suggest that Parcel builds the edited module first, sends out the update, then begins to rebuild the bundle. Then it refuses to do any other tasks until the bundle build is complete. So any additional HMR updates are delayed.

PartyWumpus · 2024-09-11T13:24:12Z

In development we don't use esm, so this is intentional. What is broken about it for you?

I'm confused, parcel watch and parcel build having totally differently functioning outputs is intentional? I understand it is not often super important that dev and prod are identical, but at least provide an option for parcel watch to output esm (or whatever, to get top level awaits working the same in both) like parcel build can...

LoganDark · 2024-09-11T13:25:51Z

I'm confused, parcel watch and parcel build having totally different outputs is intentional?

To some degree this is to be expected because production builds don't have hot reload or anything. I just hate that Parcel has to build every module into a single JS file before the webpage can even load. I wish it could build/load modules individually/lazily like Vite does. Native ESM import would be amazing.

PartyWumpus · 2024-09-11T13:29:37Z

To some degree this is to be expected because production builds don't have hot reload or anything.

Obviously the output can't actually be identical, but I would've expected it to function as if it was the same. ~~If this is just a problem with parcel's fundamental design should I just switch to vite?~~ No hate to the devs of this project, just not a fan of non-representative builds.

Edit: doesn't look like vite does what i need (it does top level await, just not some other stuff), guess i have to just rewrite the top level await stuff and just hope this isn't a problem again...

LoganDark · 2024-09-11T13:32:30Z

If this is just a problem with parcel's fundamental design should I just switch to vite?

That seems to be the consensus, according to Parcel devs? They say parcel is a bundler so if you don't want it to bundle your code then switch to something else. This is difficult to do for our company monorepo but if that's really the attitude then I'll keep pushing to switch to Vite. It doesn't exactly help that Parcel miscompiles code as well.

LoganDark · 2024-09-11T13:33:49Z

Vite supports top level await in ES modules, not sure why that would be the limiting factor here. I think Parcel also supports it but only in production builds because dev builds are CJS for no good reason...

devongovett · 2024-09-11T14:47:48Z

I'm confused, parcel watch and parcel build having totally differently functioning outputs is intentional?

That's always been the case. Minification, tree shaking, and lots of other stuff doesn't run in development. The other important difference is HMR, which requires a different module format so that modules can be replaced. Native ESM modules cannot be replaced in the browser's module cache, so we need a custom format for that. Regardless, these are implementation details and shouldn't matter too much as long as the behavior is the same.

I wish it could build/load modules individually/lazily like Vite does.

This also has some downsides. It just moves the work from the bundler to the browser. This may actually be slower because the browser needs to download many more modules on each page load, each of which has overhead, vs downloading a single bundle. We did this long before bundlers, e.g. require.js, and bundling was partially a response to this to improve performance. With many modules, bundling is faster. Vite's approach is ok for smaller apps, but slows down as your app grows.

I think this would suggest that Parcel builds the edited module first, sends out the update, then begins to rebuild the bundle. Then it refuses to do any other tasks until the bundle build is complete. So any additional HMR updates are delayed.

This seems like something we could potentially improve. But that's a totally different problem than this initial issue. Perhaps focusing on the issues you're encountering rather than the solution would be a good place to start.

PartyWumpus · 2024-09-11T14:54:53Z

Regardless, these are implementation details and shouldn't matter too much as long as the behavior is the same.

But it isn't, I can do top level awaits in one and not in the other... If you read my comment you'll notice I said "differently functioning outputs", I understand that they will, under the hood, work differently, but it's not just an "implementation detail" if it makes a noticeable difference to the end result...

Edit: To be clear, I understand if parcel doesn't/won't support top level awaits at all, but I would've preferred it not work immediately instead of breaking sometimes, because it wasted my time.

LoganDark · 2024-09-11T14:55:57Z

This seems like something we could potentially improve. But that's a totally different problem than this initial issue. Perhaps focusing on the issues you're encountering rather than the solution would be a good place to start.

I don't see the bundle as necessary whatsoever in development if the individual module can be rebuilt and applied just fine without ever even thinking about a bundle. So the most obvious solution in my eyes is to stop building everything into a single file during development. Why fix only one symptom when you can fix the root of the problem? Is Parcel determined to stay in the past or something? Is there a reason why the entire bundle has to be rebuilt every time any file changes?

I'm OK filing an issue for the HMR slowness if that sounds like something you'd be interested in fixing.

One of the main reasons I haven't already done that is because I'm pretty sure trying to do anything in parallel is what has resulted in constant "expected content key <id> to exist" errors (or in other words, "there's a good reason it's done this way"), which is why I have to restart the Parcel server nearly every time I switch branches or perform any multi-file refactors. Of course, sometimes instead of throwing any actual error, the server just craps the bed and stops rebuilding anything, even though it still responds to requests. Which is annoying as hell and also super misleading as the code in the browser is perpetually out of date until the server is restarted (which has to be achieved via kill because Ctrl-C stops working).

Not sure how valuable it would be for me to file bug reports for every issue I've ever encountered with Parcel. My experience is that many of the issues I'm having were filed years ago and no effort is being put into diagnosing or fixing them.

(If you say you're all unpaid volunteers and I'm not entitled to anything, then that's why I don't generally file issues with the expectation of them being fixed! Because I know I don't personally have time to investigate them.)

devongovett · 2024-09-11T18:27:59Z

TLA support is a different issue: #4028. Unfortunately it's quite difficult to implement.

I don't see the bundle as necessary whatsoever in development

You would definitely notice the performance issue even in development when you start loading thousands of individual modules as separate requests. This happens every time you load every page, even with browser caching, rather than only when you change a file (and we don't need to rebuild bundles for pages that didn't change). See this thread on the Vite repo for some reports from their users with large apps: vitejs/vite#4803. There are definitely tradeoffs on each side, neither option is a silver bullet.

LoganDark · 2024-09-11T18:35:57Z

Unfortunately it's quite difficult to implement

I would think so, probably because of scope hoisting or something. And also the fact that module loading suddenly becomes asynchronous, and you might want to cancel the Promises e.g. in the case of HMR.

I authored a Node.js package that let you use await at the top level of require, lmao (not in the browser, though). It's terrible, but I know from using that in practice how wide-reaching the implications can be, since suddenly every require returns a Promise. I'm guessing you'd need to have both async and non-async require if you're going to continue using CJS wrappers for ES modules. But eh, that's a discussion for another thread.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Development server inexplicably strips type="module" from <script> tag #9716

Development server inexplicably strips type="module" from <script> tag #9716

gcleaves commented May 15, 2024 •

edited

Loading

gcleaves commented May 16, 2024

josewal commented Jul 26, 2024

devongovett commented Jul 26, 2024

LoganDark commented Sep 3, 2024 •

edited

Loading

devongovett commented Sep 3, 2024 •

edited

Loading

LoganDark commented Sep 3, 2024

devongovett commented Sep 3, 2024

LoganDark commented Sep 3, 2024 •

edited

Loading

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024

LoganDark commented Sep 11, 2024 •

edited

Loading

devongovett commented Sep 11, 2024

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

devongovett commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

Development server inexplicably strips type="module" from <script> tag #9716

Development server inexplicably strips type="module" from <script> tag #9716

Comments

gcleaves commented May 15, 2024 • edited Loading

🐛 bug report

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

🤔 Expected Behavior

😯 Current Behavior

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

gcleaves commented May 16, 2024

josewal commented Jul 26, 2024

devongovett commented Jul 26, 2024

LoganDark commented Sep 3, 2024 • edited Loading

devongovett commented Sep 3, 2024 • edited Loading

LoganDark commented Sep 3, 2024

devongovett commented Sep 3, 2024

LoganDark commented Sep 3, 2024 • edited Loading

PartyWumpus commented Sep 11, 2024 • edited Loading

LoganDark commented Sep 11, 2024 • edited Loading

PartyWumpus commented Sep 11, 2024 • edited Loading

LoganDark commented Sep 11, 2024

LoganDark commented Sep 11, 2024 • edited Loading

devongovett commented Sep 11, 2024

PartyWumpus commented Sep 11, 2024 • edited Loading

LoganDark commented Sep 11, 2024 • edited Loading

devongovett commented Sep 11, 2024 • edited Loading

LoganDark commented Sep 11, 2024 • edited Loading

gcleaves commented May 15, 2024 •

edited

Loading

LoganDark commented Sep 3, 2024 •

edited

Loading

devongovett commented Sep 3, 2024 •

edited

Loading

LoganDark commented Sep 3, 2024 •

edited

Loading

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

PartyWumpus commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading

devongovett commented Sep 11, 2024 •

edited

Loading

LoganDark commented Sep 11, 2024 •

edited

Loading