Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@babel/runtime 7.13.10 breaking on JSPM #13059

Closed
1 task done
guybedford opened this issue Mar 27, 2021 · 3 comments
Closed
1 task done

@babel/runtime 7.13.10 breaking on JSPM #13059

guybedford opened this issue Mar 27, 2021 · 3 comments
Labels
i: bug i: needs triage outdated A closed issue/PR that is archived due to age. Recommended to make a new issue

Comments

@guybedford
Copy link
Contributor

guybedford commented Mar 27, 2021

Bug Report

  • I would like to work on a fix!

Current behavior

Input Code

Loading @babel/runtime@7.13.10/helpers/interopRequireWildcard.js includes a require to @babel/runtime/helpers/typeof which is mapped to resolve to @babel/runtime@7.13.10/helpers/esm/typeof.js in all environments that aren't Node.js environments by the exports definitions.

This file then also uses the import pattern:

var _typeof = require("@babel/runtime/helpers/typeof")["default"];

Where accessing the default off of the helpers/esm/typeof.js file makes _typeof undefined.

Expected behavior

"require" should not remap to an ESM module, or if it does the interop should take into account the varying signature of the exports.

Possible Solution

I'm not sure what would be best actually. Ideally using relative paths in the first place would avoid this. Alternatively using the "require" condition instead of the "node" condition. If it is really desired to replace the CJS require statements with ES modules then the Webpack / build-tool-specific "module" condition could be used.

@babel-bot
Copy link
Collaborator

Hey @guybedford! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."

@nicolo-ribaudo
Copy link
Member

nicolo-ribaudo commented Mar 27, 2021

Context (in chronological order): #12632, #12865, #12877, #12893

In #12893 I removed the require condition because I assumed that it was unnecessary since we specify node and default.

includes a require to @babel/runtime/helpers/typeof which is mapped to resolve to @babel/runtime@7.13.10/helpers/esm/typeof.js in all environments that aren't Node.js environments by the exports definitions.

I don't understand how this remapping happens. This is the exports map:

    "./helpers/typeof": [
      {
        "node": "./helpers/typeof.js",
        "import": "./helpers/esm/typeof.js",
        "default": "./helpers/typeof.js"
      },
      "./helpers/typeof.js"
    ],

I might be reading it wrong, but I would expect a non-Node.js environment using require to interpret it as such:

  • node is ignored, because the environment is not Node.js
  • import is ignored, because the helper is being require()ed
  • default matches

However, default points to a CJS file, so I would expect it to work 🤔

@guybedford
Copy link
Contributor Author

Thanks for the quick response here @nicolo-ribaudo, you're right this looks like a bug if it is incorrectly matching the "import" condition. Let me see if I can fix that up and reopen if I'm still seeing any issues.

@github-actions github-actions bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Jun 26, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
i: bug i: needs triage outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

No branches or pull requests

3 participants