Parcel 2 - Bundle codegen contains non-ie11 compatible code - but only in watch mode

[jamesrichards]

🐛 Bug

I have a project with multiple bundles using Parcel 1. We bundle on a component level so there's quite a few as you can imagine. I've tried upgrading to Parcel 2 this week but I can't seem to get IE11 working using Parcel 2's watch mode - but the build option is working fine.

🔦 Context

We use an IE11 polyfill bundle that we conditionally serve only in IE11. We don't use targets or anything fancy to serve this, its literally just added into the HTML (example below).

If I run a prod build - everything appears to work fine. But if I try to run the local dev watch task, IE throws a syntax error for all of the bundle files because there appears to still be non-compatible IE11 code present in the bundle.

💻 Examples

package.json

{
  "scripts": {
    "dev": "parcel watch ParcelBundles/*.js --public-url . --no-cache",
    "build": "parcel build ParcelBundles/*.js --public-url ."
  },
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "ie 11",
    "not ie <= 10"
  ],
  "devDependencies": {
    "@parcel/transformer-sass": "^2.0.0-beta.3.1",
    "parcel": "^2.0.0-beta.3.1"
  },
  "dependencies": {
    "@parcel/babel-plugin-transform-runtime": "^2.0.0-nightly.1823",
    "@parcel/babel-preset-env": "^2.0.0-alpha.3",
    "whatwg-fetch": "^3.6.2"
  }
}

babel.config.json

{
    "presets": [
      [
        "@parcel/babel-preset-env",
        {
          "useBuiltIns": "entry",
          "corejs": 3
        }
      ]
    ],
    "plugins": ["@parcel/babel-plugin-transform-runtime"]
}

ie11-polyfill.js

import "core-js/stable";
import "regenerator-runtime/runtime";
import "whatwg-fetch";

This is what we get for every bundle file in IE11 when running watch mode:

As I said before, running a prod build works fine.

Thanks in advance for taking a look, Parcel has been fantastic for us and we hope to continue with it in future.

[jamesrichards]

I've been looking at this issue again today. Today I looked over this closed issue #6502 which lists very similar issues I'm seeing in IE11 with trailing commas. Looks like the fixes were merged in as part of #6532

Today I've tried a clean install of 2.0.0-rc.0 instead of 2.0.0-beta.3.1. The trailing commas I was seeing are now gone as part of the PR fix, but I'm still getting issues with non IE11 compatible code generated by Parcel when running a prod build.

In the polyfill bundle:

Config is as follows:

package.json

{
  ...
  "scripts": {
    "dev": "parcel watch ParcelBundles/*.js --public-url . --no-cache",
    "build": "parcel build ParcelBundles/*.js --public-url . "
  },
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "ie 11",
    "not ie <= 10"
  ],
  "devDependencies": {
    "@parcel/transformer-image": "^2.0.0-rc.0",
    "@parcel/transformer-sass": "^2.0.0-rc.0"
  },
  "dependencies": {
    "es6-promise": "^4.2.8",
    "parcel": "^2.0.0-rc.0",
    "whatwg-fetch": "^3.6.2"
  }
}

I removed the babel config file as I'm just using default settings and browser targets specified above. Would really appreciate any input on this - thank you 🙏

[basher]

I'm having similar problems with IE11 using Parcel 2.0.0-rc.0.

I don't use a .babelrc file.

I simply have the following in my package.json:

"browserslist": [
    "defaults"
  ],
  "targets": {
    "app": {}
  }

And my start command executes parcel src/ts/index.ts --port 1234 --no-cache --no-hmr --target app

Transpiled index.js contains 64 arrow functions which are inside parcelHelpers.export() functions.

[mischnic]

And my start command executes parcel src/ts/index.ts --port 1234 --no-cache --no-hmr --target app

I get something like that in your case:

parcelHelpers.export(exports, "x", function() {
    return x;
});

[basher]

Hi @mischnic

I'm trying to create a simple test case where I can reproduce the issue and share the repo.

In the meantime, in my work/private repo, I've re-installed Parcel V2 RC0 again and I'm still seeing the same issues.

For components/modules that I've created (e.g. an accordion), the transpiled code is OK:

parcelHelpers.export(exports, "Accordion", function() {
    return Accordion;
});

But for other code (which I'm assuming are to do with various polyfills I've added), I still get arrow functions with the parcel start command.

For example:

parcelHelpers.export(exports, "applyDecoratedDescriptor", ()=>_applyDecoratedDescriptorDefault.default
);
parcelHelpers.export(exports, "arrayWithHoles", ()=>_arrayWithHolesDefault.default
);
parcelHelpers.export(exports, "arrayWithoutHoles", ()=>_arrayWithoutHolesDefault.default
);
parcelHelpers.export(exports, "assertThisInitialized", ()=>_assertThisInitializedDefault.default
);
parcelHelpers.export(exports, "asyncGenerator", ()=>_asyncGeneratorDefault.default
);
parcelHelpers.export(exports, "asyncGeneratorDelegate", ()=>_asyncGeneratorDelegateDefault.default
);
parcelHelpers.export(exports, "asyncIterator", ()=>_asyncIteratorDefault.default
);
parcelHelpers.export(exports, "asyncToGenerator", ()=>_asyncToGeneratorDefault.default
);
parcelHelpers.export(exports, "awaitAsyncGenerator", ()=>_awaitAsyncGeneratorDefault.default
);
parcelHelpers.export(exports, "awaitValue", ()=>_awaitValueDefault.default
);

[mischnic]

But for other code (which I'm assuming are to do with various polyfills I've added), I still get arrow functions with the parcel start command.

So code imported from node_modules makes Parcel emit arrow functions ?!

Caused by this

parcel/packages/transformers/js/src/JSTransformer.js

Line 291 in f03eddd

if (asset.isSource) {

[basher]

@mischnic

I now have a public repo where I can reproduce my issues with non-transpiled arrow functions.

The repo is a simplification of everything I need for our production setup at work (i.e. Sass & PostCSS, TypeScript& ES6+, differential bundling, dynamically imported polyfills, linters & prettier).

• npm start
• Look at the polyfills.js which contains the arrow functions.

Hopefully this will help you. :)

[mischnic]

I was able to reproduce this with just

import {add} from "lodash-es";
console.log(add(1,2));

Then all modules from lodash-es contain parcelHelpers.export with arrow functions.

[basher]

Hi @mischnic - is there any update on this?

[thewilkybarkid]

Not sure if my problem is actually related or not, but I'm currently struggling to update a Node (14) app from beta-1 to 2.0.0 (using the TSC transformer). Looking at the code generated by beta-1 without optimization/scope-hoisting it's like:

_parcelHelpers.export(exports, "Badge", function () {
  return Badge;
});
[...]
let Badge = class Badge extends _BaseEntity.BaseEntity {
[...]

With 2.0.0 it's like:

parcelHelpers.export(exports, "Badge", ()=>Badge2
) //# sourceMappingURL=Badge.js.map
;
[...]
let Badge2 = class Badge1 extends _baseEntity.BaseEntity {
[...]

The latter doesn't work due to the scoping difference of arrow functions, leading to ReferenceError: Cannot access 'Badge2' before initialization errors.

[basher]

Hi @mischnic,

Can I ask for some clarity on this issue?

Is it related to PR 7293 raised by @thewilkybarkid ?

I'm keeping my fingers crossed that the PR will fix it! ;)

[mischnic]

No, the problem here is that the targets are only forwarded to the Rust side for source assets.

parcel/packages/transformers/js/src/JSTransformer.js

Line 284 in 8cabeae

if (asset.isSource) {

with the original intention that preset_env shouldn't apply for non-source assets:

parcel/packages/transformers/js/core/src/lib.rs

Lines 306 to 312 in 8cabeae

	let versions = targets_to_versions(&config.targets);
	if let Some(versions) = versions {
	preset_env_config.targets = Some(Targets::Versions(versions));
	preset_env_config.shipped_proposals = true;
	preset_env_config.mode = Some(Entry);
	preset_env_config.bugfixes = true;
	}

These parcelHelpers.export calls are generated by this call.

parcel/packages/transformers/js/core/src/lib.rs

Line 427 in 8cabeae

let (module, needs_helpers) = esm2cjs(module, versions);

So the solution here would be to basically always forward the targets and move that if(isSource) check to that preset_env_config.targets = .. assignment instead.

Though #7345 (comment) would just remove that whole if(isSource) check entirely which would also solve this problem.

[newtriks]

We're having the exact same issue when running the parcel (v2.5.0) dev server as this comment #6676 (comment).

We've tried multiple work arounds but the node_modules simply do not get transpiled and this is regardless of setting/amending targets, .browserslistrc, with and without watch mode, etc. Basically, IE 11 will not work against the parcel dev server.

I've followed threads around this repo which seem to indicate this being fixed, then others stating it's not. Can anyone shed some light e.g. maintainers as to what the actual status is as this seems very easy to reproduce and there's a lot of noise surrounding Parcel 2 and similar issues?

[mischnic]

This can indeed still happens when scope hoisting isn't used (so also yarn build index.js --no-scope-hoist in a "prod build").

@newtriks In which code do you still see arrow functions like these? (And also: is there any other IE-incompatible code you're getting?)

parcelHelpers.export(exports, "applyDecoratedDescriptor", ()=>_applyDecoratedDescriptorDefault.default);

AFAICT, this only happens for everything inside files from the @swc/helpers package anymore, but not for any other package.