Distinguish between module and classic scripts #5398

devongovett · 2020-11-29T04:28:26Z

Whew, this turned out way bigger than I expected... 😂

This changes the way script tags are treated in HTML to distinguish between classic scripts and ES modules, improves Parcel's web compatibility, and introduces automatic modern-by-default optimizations for production builds.

import, export, require, and all Node polyfill features are now only allowed in <script type="module"> contexts (both inline and linked). Classic <script> elements can still have dynamic import(), Worker, SharedWorker, and navigator.serviceWorker.register dependencies. This matches what browsers support more closely, and allows better interoperability with legacy scripts where e.g. require being processed by Parcel was unexpected.
Classic <script> now works just like the browser - global variables are truly global. The bundle is not wrapped in a function, so top-level variables are accessible between scripts on the page, in HTML event handler attributes, etc. See e.g. Possible Bug: Parcel is commenting out my JS #5378. By default, when there are no dependencies, the script is not processed at all by Parcel. However, when an async dependency is seen that may require us to inject a runtime, we do wrap the bundle in a function to avoid unintended globals, but the globals seen in the original source are hoisted for compatibility.
In addition, <script type="module"> is now automatically compiled to both a modern ES module version and also a legacy <script nomodule> version if the browser targets do not all support ES modules natively. If no browserslist or target config is specified, then only a modern ES module version is output. For inline scripts, only a single script is output in order to avoid duplicating content - a modern version if all targets support it, otherwise legacy.
The same rules also apply in other scenarios, including web workers and service workers. These now require the type: 'module' option just like in the browser to use ES modules, otherwise they will behave just like as described above for classic scripts. Workers are compiled to ES modules natively if all browser targets support them, otherwise they are compiled to a classic script instead.

When an import or export is found in a classic script, we show an error message that indicates both where the dependency is, as well as where the environment was originally instantiated.

This also resulted in adding support for multiple contexts at once in an environment. For example, an asset may have both "browser" and "script" as its environment. This may have other uses later on. I also added a method to the environment object to allow easier checking if it supports a particular feature. There's basic data for things like esmodules, dynamic imports, etc. so far, but ideally we'd get this data from somewhere else that we don't need to maintain ourselves. Finally, environments also now support a loc property to track the source location where they were originally created, mostly for error messaging purposes.

One other change due to the multi-environment support is that I changed the config format to no longer configure runtimes per context, and instead just have a single pipeline. The reality was that all of the contexts used the same runtime plugin anyway, and if the runtimes are context specific, they can check internally themselves.

Close T-554, Close T-136

height · 2020-11-29T04:28:28Z

This pull request has been linked to and will mark 2 tasks as "Done" when merged:

~~T-136 Compile a single script into multiple with module/nomodule automatically~~ (unlink task)
~~T-554 Remove context mapping from runtimes config~~ (unlink task)

devongovett · 2020-11-29T04:41:02Z

packages/utils/posthtml-parser/index.js

@@ -0,0 +1,198 @@
+const {Parser} = require('htmlparser2');
+


I will be sending a PR to posthtml for this

devongovett · 2020-11-29T04:46:39Z

packages/shared/babel-ast-utils/src/index.js

@@ -36,6 +36,8 @@ export async function parse({
 strictMode: false,
 sourceType: 'module',
 plugins: ['exportDefaultFrom', 'exportNamespaceFrom', 'dynamicImport'],
+ // $FlowFixMe
+ startLine: asset.meta.loc?.start.line,


This offsets location information for both error messages and source maps of inline JS assets inside HTML so it starts at the correct line number of the original file

devongovett · 2020-11-29T04:48:37Z

packages/transformers/html/src/dependencies.js

+ seen.add(copy);
+ }
+
+ attrs.src = asset.addURLDependency(attrs.src, {


A thought: both of these dependencies count against the parallel request limit, but only one will actually be downloaded. How should we represent that in the graph? 🤔

mischnic · 2020-12-03T17:51:50Z

I think this should resolve #333?

mischnic · 2021-01-01T13:58:10Z

packages/core/core/src/Environment.js

+ for (let context of ctx) {
+ switch (context) {
+ case 'node':
+ case 'electron-main':
+ case 'electron-renderer':
+ includeNodeModules = false;
+ break;
+ case 'browser':
+ case 'web-worker':
+ case 'service-worker':
+ default:
+ includeNodeModules = true;
+ break;
+ }


So it depends on the order of the contexts? Maybe actually throw an error if there are conflicting values?

mischnic · 2021-01-01T14:08:51Z

packages/core/test-utils/src/utils.js

+ );
+ }
+
+ let prepareCode = (code, b) => {


~~Should we do #5548 instead?~~

prepareCode shouldn't be necessary anymore

mischnic · 2021-01-01T14:12:51Z

packages/core/core/src/BundleGraph.js

@@ -615,7 +620,7 @@ export default class BundleGraph {
 visitedBundles.add(descendant);
 if (
 descendant.type !== bundle.type ||
- descendant.env.context !== bundle.env.context
+ !isSubset(descendant.env.context, bundle.env.context)


isSubset() checks a subset of b OR b subset of a. But doesn't the previous "context changes" translate to "child context contains something that the parent doesn't support"? So only child not subset of parent?

(so context gets more specific/refined vs is widened)

mischnic · 2021-01-01T14:30:27Z

Are JS entry points assigned the module context?

devongovett · 2021-01-01T18:14:51Z

Are JS entry points assigned the module context?

At the moment they have neither script or module. Actually, module is pretty much unused, we only check for script.

mischnic · 2021-02-16T18:21:01Z

In the longer term, this could enable us to do something like Webpack 5's strict module mode (e.g. because of type: "modlue" in package.json) which disables some deprecated features.

devongovett · 2021-05-09T04:24:17Z

Closing in favor of #6247

devongovett commented Nov 29, 2020

View reviewed changes

devongovett force-pushed the html-script branch from ea9c296 to da776f8 Compare November 29, 2020 04:43

devongovett commented Nov 29, 2020

View reviewed changes

Distinguish between module and classic scripts

aab04e5

devongovett force-pushed the html-script branch from da776f8 to aab04e5 Compare November 29, 2020 04:58

mischnic mentioned this pull request Nov 29, 2020

Mention that all JS assets are treated as modules (regarding variables being global) parcel-bundler/website#775

Open

mischnic mentioned this pull request Dec 20, 2020

Support <script type="module"> when serving with HMR #5077

Closed

3 tasks

mischnic reviewed Jan 1, 2021

View reviewed changes

mischnic mentioned this pull request Jan 1, 2021

Changes for html-scripts PR parcel-bundler/website#787

Open

This was referenced Feb 24, 2021

new Worker(new URL(...), { type: "module" }) results in invalid code #5920

Closed

Parcel 2 does not generate nomodule script #5945

Closed

wbinnssmith mentioned this pull request Mar 18, 2021

Recursively check reachability when removing asset graphs from bundles in deduplication #6004

Merged

2 tasks

mischnic mentioned this pull request Apr 30, 2021

[Parcel 2] build breaks inline script tag for external library #6213

Closed

devongovett mentioned this pull request May 9, 2021

Implement support for classic scripts and automatic module/nomodule #6247

Merged

devongovett closed this May 9, 2021

mischnic deleted the html-script branch May 13, 2021 16:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Distinguish between module and classic scripts #5398

Distinguish between module and classic scripts #5398

devongovett commented Nov 29, 2020 •

edited by mischnic

Loading

height bot commented Nov 29, 2020 •

edited

Loading

devongovett Nov 29, 2020

devongovett Nov 29, 2020

devongovett Nov 29, 2020

mischnic commented Dec 3, 2020

mischnic Jan 1, 2021

mischnic Jan 1, 2021 •

edited

Loading

mischnic Jan 1, 2021 •

edited

Loading

mischnic commented Jan 1, 2021

devongovett commented Jan 1, 2021

mischnic commented Feb 16, 2021

devongovett commented May 9, 2021

Distinguish between module and classic scripts #5398

Distinguish between module and classic scripts #5398

Conversation

devongovett commented Nov 29, 2020 • edited by mischnic Loading

height bot commented Nov 29, 2020 • edited Loading

devongovett Nov 29, 2020

Choose a reason for hiding this comment

devongovett Nov 29, 2020

Choose a reason for hiding this comment

devongovett Nov 29, 2020

Choose a reason for hiding this comment

mischnic commented Dec 3, 2020

mischnic Jan 1, 2021

Choose a reason for hiding this comment

mischnic Jan 1, 2021 • edited Loading

Choose a reason for hiding this comment

mischnic Jan 1, 2021 • edited Loading

Choose a reason for hiding this comment

mischnic commented Jan 1, 2021

devongovett commented Jan 1, 2021

mischnic commented Feb 16, 2021

devongovett commented May 9, 2021

devongovett commented Nov 29, 2020 •

edited by mischnic

Loading

height bot commented Nov 29, 2020 •

edited

Loading

mischnic Jan 1, 2021 •

edited

Loading

mischnic Jan 1, 2021 •

edited

Loading