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

When entrypoint fails to resolve via ESM, fallback to CommonJS resolution #1649

Closed
cspotcode opened this issue Feb 19, 2022 · 0 comments · Fixed by #1654
Closed

When entrypoint fails to resolve via ESM, fallback to CommonJS resolution #1649

cspotcode opened this issue Feb 19, 2022 · 0 comments · Fixed by #1654
Milestone

Comments

@cspotcode
Copy link
Collaborator

cspotcode commented Feb 19, 2022

Alternative to #1611. Maybe I could tweak #1611, but I dunno, I'd prefer to track the two ideas as separate tickets.

Based on nodejs/node#41711, it seems likely that the node team is going to implement special-casing for the resolution of entrypoints.
If an entrypoint fails to resolve via the ESM loader, node will fallback to using the CommonJS resolver and setting the format to CommonJS. This handles extensionless entrypoints such as mocha's bin entrypoint.

We can do the same in our --loader, as a stop-gap until node fixes the bug on their end. resolve() invocations without parentURL can be assumed to be the entrypoint. For these requests:

  • if resolve() returns an error, try require.resolve() and return that
  • if load() / getFormat() returns an error, try returning format CommonJS

Won't be perfect, but should be good enough to unblock people while the node team figures out semantics. Once they've got that figured out, we can adjust our behavior to align, and eventually remove this hack.

Gotchas

load() does not receive parentURL, so we'll need to maintain a side-channel where we store that we have guessed a resolution is the entrypoint. Doesn't need to be perfect because this is a hack anyway.

@cspotcode cspotcode added this to the 10.6.0 or 10.5.1 milestone Feb 19, 2022
@cspotcode cspotcode modified the milestones: 10.6.0 or 10.5.1, next Feb 21, 2022
cspotcode added a commit that referenced this issue Feb 22, 2022
…o CommonJS resolution (#1654)

* WIP

* fix

* rather than throw our own error, throw the error from node's ESM loader
@cspotcode cspotcode modified the milestones: next, 10.6.0 or 10.5.1 Feb 23, 2022
crapStone pushed a commit to Calciumdibromid/CaBr2 that referenced this issue Mar 8, 2022
This PR contains the following updates:

| Package | Type | Update | Change |
|---|---|---|---|
| [ts-node](https://typestrong.org/ts-node) ([source](https://github.com/TypeStrong/ts-node)) | devDependencies | minor | [`10.5.0` -> `10.6.0`](https://renovatebot.com/diffs/npm/ts-node/10.5.0/10.6.0) |

---

### Release Notes

<details>
<summary>TypeStrong/ts-node</summary>

### [`v10.6.0`](https://github.com/TypeStrong/ts-node/releases/v10.6.0)

[Compare Source](TypeStrong/ts-node@v10.5.0...v10.6.0)

Questions about this release? Ask in the official discussion thread: [#&#8203;1666](TypeStrong/ts-node#1666)

**Added**

-   Adds workaround for extensionless entrypoints with ESM loader ([#&#8203;1649](TypeStrong/ts-node#1649), [#&#8203;1654](TypeStrong/ts-node#1654))
    -   You can now combine tools such as `mocha` with `--loader ts-node/esm`, where previously node would throw `[ERR_UNKNOWN_FILE_EXTENSION]`
    -   node has a bug where combining `--loader` with an extensionless entrypoint causes this error [nodejs/node#&#8203;33226](nodejs/node#33226)
    -   Some tools, for example `mocha`, have an extensionless entrypoint. ([source](https://github.com/mochajs/mocha/blob/547ffd73535088322579d3d2026432112eae3d4b/package.json#L37), [source](https://github.com/mochajs/mocha/blob/547ffd73535088322579d3d2026432112eae3d4b/bin/mocha))
    -   Combining `NODE_OPTIONS=--loader ts-node/esm` with these tools causes this error.  [mochajs/mocha#&#8203;4645](mochajs/mocha#4645)
    -   node intends to fix this bug in a future release: [nodejs/node#&#8203;41711](nodejs/node#41711)
    -   In the interim, we have implemented a workaround in ts-node.
-   Adds support for target "ES2022" in `moduleTypes` overrides ([#&#8203;1650](TypeStrong/ts-node#1650))

**Fixed**

-   Fixed bug where `--swc` and other third-party transpilers did not respect `moduleTypes` overrides ([#&#8203;1651](TypeStrong/ts-node#1651), [#&#8203;1652](TypeStrong/ts-node#1652), [#&#8203;1660](TypeStrong/ts-node#1660))
-   Fixed bug where node flags were not preserved correctly in `process.execArgv` ([#&#8203;1657](TypeStrong/ts-node#1657), [#&#8203;1658](TypeStrong/ts-node#1658))
    -   This affected `child_process.fork()`, since it uses `process.execArgv` to create a similar child runtime.
    -   With this fix, `child_process.fork()` will preserve both node flags and `ts-node` hooks.
-   Fixed compatibility TypeScript 4.7's API changes ([#&#8203;1647](TypeStrong/ts-node#1647), [#&#8203;1648](TypeStrong/ts-node#1648))

https://github.com/TypeStrong/ts-node/milestone/9

</details>

---

### Configuration

📅 **Schedule**: At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

Co-authored-by: cabr2-bot <cabr2.help@gmail.com>
Reviewed-on: https://codeberg.org/Calciumdibromid/CaBr2/pulls/1195
Reviewed-by: Epsilon_02 <epsilon_02@noreply.codeberg.org>
Co-authored-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
Co-committed-by: Calciumdibromid Bot <cabr2_bot@noreply.codeberg.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant