Skip to content

fix: swallow more require errors from *ts files#5498

Merged
mark-wiemer merged 12 commits intov11.xfrom
v11-fix-5494
Oct 14, 2025
Merged

fix: swallow more require errors from *ts files#5498
mark-wiemer merged 12 commits intov11.xfrom
v11-fix-5494

Conversation

@mark-wiemer
Copy link
Copy Markdown
Member

@mark-wiemer mark-wiemer commented Oct 10, 2025

PR Checklist

Overview

In #5494, users reported requireErr being thrown when importErr should've been thrown instead. Recent change #5408 accidentally throws requireErr when the file is a *ts file or importErr.code === 'ERR_UNKNOWN_FILE_EXTENSION'. This condition should've been and, because we don't want to throw the earlier requireErr when the later importErr is meaningful (e.g. from a *ts file but not an unknown file extension).

Per research into #5361 (comment), we know Node's loader / "customization hook" behavior changes whether the parent package is in module mode or not. Because our CI tests run through nyc, Node was always "primed" to import modules, so importErr and requireErr were the same in tests that expected them to be different. This is why we didn't detect the issue earlier.

This PR adds test-node-integration:bare to the only test that needs it. Bare tests are run directly via npx mocha to avoid accidentally "priming" Node to import modules.

(This is a PR into the new v11.x branch, so we'll have to find a way to push 11.7.5 instead of 12.0.0-beta-1. Not sure if we want this to be a one-off for now or work towards a high-resilience deployment system. We haven't defined our support of old Mocha versions, but I believe we should be generous in backporting given our userbase)

@mark-wiemer mark-wiemer marked this pull request as draft October 10, 2025 13:19
@mark-wiemer
Copy link
Copy Markdown
Member Author

mark-wiemer commented Oct 10, 2025

See run 4329 for test results

@mark-wiemer
Copy link
Copy Markdown
Member Author

No new failures, ready for review. Though Coveralls was down so all test jobs failed 😭 I checked the integration ones and nothing went wrong there!

@mark-wiemer mark-wiemer marked this pull request as ready for review October 11, 2025 01:31
Copy link
Copy Markdown
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.

Thank you for so thoroughly covering this silly oversight of mine! +1 to the new form of test coverage.

Comment thread .github/DEVELOPMENT.md Outdated
Comment thread .github/DEVELOPMENT.md Outdated
Comment thread test/integration/esm.spec.js
mark-wiemer and others added 2 commits October 14, 2025 09:08
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
Co-authored-by: Josh Goldberg ✨ <git@joshuakgoldberg.com>
@mark-wiemer mark-wiemer merged commit d89dbaf into v11.x Oct 14, 2025
1 of 2 checks passed
@mark-wiemer mark-wiemer deleted the v11-fix-5494 branch October 14, 2025 16:11
@mark-wiemer
Copy link
Copy Markdown
Member Author

Postmortem

I never fully wrapped my head around the exact problem here. Why was Node loading modules in a different way based on whether nyc had been enabled? How can we track that to diagnose future issues?

I'll be updating this comment as I reflect more, I plan to reproduce the issue in excruciating detail so that I can summarize it precisely.

Open questions

  • What is a customization hook?
  • How does Node's module loading system work?
  • How can I get docs for an exact patch version of Node, not just LTS?

References


@mark-wiemer
Copy link
Copy Markdown
Member Author

@copilot draft a report about why this error happened, it's quite complex. Organize sources so that the report is readable. Try to answer the open questions in this comment thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants