Allow more filtering options to make compiling a subset of TypeScript files faster

[mihaip]

• Rollup Plugin Name: @rollup/plugin-typescript
• Rollup Plugin Version: 8.1.0

Expected Behavior / Situation

I work in a large monorepo where several bundles are produced from a pool of TypeScript files in a src/ directory. I'm in the process of migrating to the standard Rollup TypeScript plugin, and I observed much slower performance when generating our small bundles. "small" in this case means that for the given entry file, only a few source files are reachable. The plugin appears to be loading all files into the TypeScript compiler, which spends a long time processing all of them.

We have a single tsconfig.json file that we use, and our old custom plugin could control which files the TypeScript compiler considered. I have experimented with the includes plugin option, but it is too aggressive (it filters out both the initial files and the output files).

Actual Behavior / Situation

See above. In extreme cases, compilation ends up looking at ~2,000 files instead of the expected ~50.

Modification Proposal

One option would be to give more control over how the the includes option is used. From what I can tell, it is turned into a filter predicate function that is applied both to 1) the set of filenames that are fed into the TypeScript compiler and 2) to the set of files that the plugin will handle when loading. 1) is desirable for my usecase, but 2) is not.

Another option would be to give more control over how the tsconfig/fileNames set is generated. Right now compiler options can be passed in to the plugin options, but that is a subset of tsconfig.json. The tsconfig option can only be used to specify a path. If it also supported a JSON serialization and/or a ParsedCommandLine instance that I coul dgenerate

#287 appears to be somewhat related to this (as far as being about TypeScript outputs), but I don't think it's the same.

[mihaip]

For now I have worked around this by dynamically generating a tsconfig.json file where files is set to that bundle's entrypoint. Since the file is read immediately when the plugin is instantiated, I can remove it after, thus simplifying cleanup.

[shellscape]

I'm certain we'd be open to this. We're currently seeking as much help as we can with the typescript plugin, so if you'd like to get involved, we'd welcome it.

[shellscape]

@mihaip going through issues tonight and it looks like this might be the same as what's described in #753

[stale]

Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it. ⓘ

[kevincox]

I would definitely like to see this treat the rollup "input' files as the entrypoints and only compile included files.

In my use case I have a few entrypoints that are run in a different context and need different compiler options. For example I have one non-module script that is loaded synchronously on page load and can't be isolated, I have a regular module async-loaded and I have a service worker. Right now I get errors because each of these entrypoints is attempted to be compiled by each input. For now I have to manage manual exclude settings for each entrypoint to exclude the others. However this is annoying because I need to basically redefine my dependency graph in these settings (as some files are included by multiple entrypoints and some are not able to be). If the typescript compiler's regular files logic was used it would automagically work, and still give errors when I included a file that isn't compatible with the current entrypoint.

I think the proposal in the initial comment is spot-on. I would like to not have to not exclude files but have the files setting be set to the entry point.