Skip to content

Conversation

mshima
Copy link
Contributor

@mshima mshima commented Jun 20, 2025

PR Checklist

Overview

Current implementation only forwards to import if the error is ERR_REQUIRE_ASYNC_MODULE which is wrong since node loaders can do file name conversion like loading a .ts file instead of .js file.

This PR always tries to import a module that failed to be required.
This implementation sounds more correct since old behavior was to always use import.

Related to #5366.

Copy link

linux-foundation-easycla bot commented Jun 20, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

@voxpelli
Copy link
Member

@mshima Can you sign the CLA? Also: See #5382 and #5383

@voxpelli voxpelli requested a review from Copilot June 23, 2025 08:35
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR updates the fallback mechanism when requiring modules by removing the conditional check for asynchronous modules and always falling back to importing.

  • Removes specific error code check for ERR_REQUIRE_ASYNC_MODULE
  • Always uses formattedImport on require failure in the esm-utils module
Comments suppressed due to low confidence (1)

lib/nodejs/esm-utils.js:96

  • Changing the fallback to always use formattedImport on require failure may inadvertently mask errors that are not related to asynchronous modules. Please verify that this behavior aligns with the intended API design.
    // Import if require fails.

Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
@mshima mshima marked this pull request as ready for review June 23, 2025 14:00
@mshima
Copy link
Contributor Author

mshima commented Jun 23, 2025

Seems to fix the error locally using node 22, could not reproduce the same error that happened in CI using node 24..

@voxpelli
Copy link
Member

Would be good to get at least some level of tests in that verifies this, to ensure it stays fixed.

How comfortable are you with adding tests for this? See eg. #5382 and #5383

@JoshuaKGoldberg
Copy link
Member

#5383's added testing passes with this change for me on Node.js 22.10.0, 22.12.0, and 24.2.0.

I'm still testing out other issue repros, but if all goes well I'd say we merge this PR then, merge #5383 right after.

Aside: #5376 tracks existing integration test failures. Those aren't something we need to address here.

@JoshuaKGoldberg JoshuaKGoldberg changed the title always fallback to import if requiring esm module fails fix: always fallback to import if requiring esm module fails Jun 23, 2025
@JoshuaKGoldberg JoshuaKGoldberg changed the title fix: always fallback to import if requiring esm module fails fix: always fallback to import() if require() fails Jun 23, 2025
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix looks great to me, thank you! Confirmed locally that all 3 currently reported issues from users are resolved by this change.

Just thinking out load: it makes sense to me that the logic should fall back to the traditional import() style loading if require() fails. There isn't a comprehensive list anywhere of the various ways folks have hooked into module loading. This change has us now use the legacy behavior as a catch-all for legacy behavior, rather than one known case. 👍

@jdmarshall
Copy link

I will check this out later today and see how it goes.

@voxpelli
Copy link
Member

Only reason not to do this would be to fail fast in cases we know will fail in both – and optimizing to fail fast feels like a very low priority.

So I'm 👍👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants