Skip to content

feat: Run external check in cli/run/loadConfigFile.ts as last in order to allow handling of e.g. workspace package imports in TS monorepos correctly#6038

Merged
lukastaegert merged 4 commits intorollup:masterfrom
stazz:master
Aug 27, 2025

Conversation

@stazz
Copy link
Copy Markdown
Contributor

@stazz stazz commented Jul 28, 2025

This PR contains:

  • bugfix (might be considered bugfix as well tbh)
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes
  • no

The first commit adds a test to test/cli/samples/config-ts-with-workspace-refs, which failed with the unmodified Rollup code.
The second commit included changes to the cli/run/loadConfigFile.ts which made the test pass.

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

List any relevant issue numbers:

Resolves #6037 .

Description

  • Make existing externality check operating purely on import string contents run as last check via resolveId of additional plugin added after all plugins from commandline have been added.

In case of TS config files (probably vast majority of usecase of --configPlugin), this will cause workspace imports to be correctly resolved to internal dependencies.

@vercel
Copy link
Copy Markdown

vercel bot commented Jul 28, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
rollup Ready Ready Preview Comment Aug 27, 2025 1:51am

@stazz stazz changed the title Enhance external check in cli/run/loadConfigFile.ts to handle e.g. workspace package imports in TS monorepos feat: Enhance external check in cli/run/loadConfigFile.ts to handle e.g. workspace package imports in TS monorepos Jul 28, 2025
@stazz
Copy link
Copy Markdown
Contributor Author

stazz commented Jul 28, 2025

I had to force-push to my forked repo because apparently first commit accidentally had wrong author :)

@codecov
Copy link
Copy Markdown

codecov bot commented Aug 24, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.79%. Comparing base (8b6b06b) to head (8eef864).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #6038   +/-   ##
=======================================
  Coverage   98.79%   98.79%           
=======================================
  Files         271      271           
  Lines       10620    10622    +2     
  Branches     2838     2840    +2     
=======================================
+ Hits        10492    10494    +2     
  Misses         88       88           
  Partials       40       40           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Copy Markdown
Member

@lukastaegert lukastaegert 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 taking action here! However, the longer I look at this, the more problems I see with that approach. You already discovered some:

  • no plugin context
  • no support for async handlers

But the bigger issue for me that it is really complex and basically needs to reimplement the plugin logic from Rollup core.

And above all, the resolveId hook from the TypeScript plugin IS already running in your cases. It just has lower precedence than the external check, or rather, the external check runs first.

So why not go into a different direction: Instead of using the external option in loadConfigFile.ts, add a plugin AFTER addPluginsFromCommandOption (and/or make this a plugin with order: "post") which marks ids as external using the same logic that is currently used in the external check? That would be simple, solve all issues, and not require another config option, wouldn't it?

@stazz
Copy link
Copy Markdown
Contributor Author

stazz commented Aug 24, 2025

Thank you for taking time to review this and provide suggestions! 🙌

The suggestion by @lukastaegert makes quite a bit of sense. I will experiment locally and see if with that approach, the workspace references used within rollup.config.ts will start to work. 👍

…ch simulates situation where rollup.config.ts imports package which looks like external, but is actually part of workspace. The test fails with expected error message now.
… config files, move externality check to be done as fallback instead of primary check.
@stazz
Copy link
Copy Markdown
Contributor Author

stazz commented Aug 25, 2025

I think I got it now. All tests, including added one, pass locally now, except some flaky one, which passes when run separately via --grep. 👍

@stazz stazz changed the title feat: Enhance external check in cli/run/loadConfigFile.ts to handle e.g. workspace package imports in TS monorepos feat: Run external check in cli/run/loadConfigFile.ts as last in order to allow handling of e.g. workspace package imports in TS monorepos correctly Aug 25, 2025
@TrickyPi
Copy link
Copy Markdown
Member

TrickyPi commented Aug 26, 2025

I noticed a few redundant parts in the test and simplified them directly in the PR.

After submitting this commit, I realized that the test in this PR could be simplified. It might be enough to just verify that the TypeScript files in node_modules build correctly, without considering symbolic links.

@stazz
Copy link
Copy Markdown
Contributor Author

stazz commented Aug 26, 2025

@TrickyPi All right, fair enough! It's true that it had this complex case of symlinking and such - I was trying to recreate the situation which produced the original problems as closely as possible within the test. Looks like current test passes with changes to cli/run/loadConfigFile.ts, and fails if I revert those changes, so I am happy with that. The simpler, the better! 👍

Can't wait for the Rollup release after this gets merged, it will make a lot of plumbing code at the project I am working at simply disappear. 🙌

@TrickyPi
Copy link
Copy Markdown
Member

Hmm, maybe keeping the symbolic links that exist in a real workspace is better, since that’s what this PR wants to fix.

Copy link
Copy Markdown
Member

@lukastaegert lukastaegert left a comment

Choose a reason for hiding this comment

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

Looks good to me, thanks for taking the time, this will probably benefit many others!

@lukastaegert lukastaegert added this pull request to the merge queue Aug 27, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Aug 27, 2025
@stazz
Copy link
Copy Markdown
Contributor Author

stazz commented Aug 27, 2025

That Test Node 18.20.0 (aarch64-apple-darwin) failure looks like some transient one, I think? At least I'm not sure how it could be related to changes in this PR. 🤔

@lukastaegert lukastaegert added this pull request to the merge queue Aug 27, 2025
@lukastaegert
Copy link
Copy Markdown
Member

Yes, this is sometimes flaky. I will need to find a way to stabilize it. In the meantime, I will just retry

Merged via the queue into rollup:master with commit 6b06476 Aug 27, 2025
42 checks passed
@github-actions
Copy link
Copy Markdown

This PR has been released as part of rollup@4.49.0. You can test it via npm install rollup.

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.

Importing workspace projects in TS config files

3 participants