Closed agilgur5 closed 2 years ago
- While #211 says rpt2 shouldn't process those, I don't necessarily agree with that statement, because
tsc
will process those. Not processingparsedConfig.fileNames
would mean only processing the Rollupinput
, acting as if thetsconfig
hadfiles
with only that single file from the Rollupinput
in it. That behavior could make sense to some, but not others, so I'm not sure that that's ideal. [...] These files may not be considered part of the Rollup "bundle" however, so I could see an argument for either direction.
I happened to stumble upon this yesterday -- it turns out that ts-loader
(in Webpack-land) actually does this as well, acting like tsc
by default, with the onlyCompileBundledFiles
option available to do, as named, only consider files that are part of the "bundle".
So doing the same as ts-loader
's default is probably optimal community-wise. I don't think we necessarily need the onlyCompileBundledFiles
option though, as the same is achievable by changing tsconfig
files
(in a tsconfigOverride
, for instance)
There is a conflict with previous PR, but otherwise looks good
Fixed the conflict 👍
~NOTE: this is built on top of #403 as it changes its code a bit. #403 is itself built on top of #386. As such, I've marked this PR as "Draft" until those PRs are merged.~ Rebased on top and marked as ready for review. (surprisingly clean rebase)
Also this might be the first time this repo has more open PRs than open issues 😮
Summary
Completely handle the long-standing issue of type-only imports
resolveId
hook now, which adds them to the cache (callscache().setDependency
)include
globs, but this PR fixes it in all other scenarios as well (namely when usingfiles
instead ofinclude
globs)Details
result.references
is populated byts.preProcessFile
; i.e. this is TS discovering all imports, instead of Rollupthis.resolve
andthis.load
to make them go through Rollup'sresolveId
->load
->transform
hooksadd a test for this that uses a
tsconfig
files
array, ensuring that theinclude
workaround won't cover these type-only filesindex
in this committype-only-import-import
, to theno-errors
fixture to ensure that we're not just checking imports one level deep, and actually going through type-only imports of type-only imports as wellthis.load
failed this checkrefactor(test): make the integration tests more resilient to output ordering changes
this.load
, the ordering of declaration and declaration map outputs in the bundle changedwatch
tests did not rely on this ordering and as such did not need to change due to the ordering changefindName
helper that will search theoutput
array instead, ensuring that most ordering does not matteroutput[0]
being the bundled JS (ESM) file, howeverrefactor(test): go through a
files
array for tests that check for multiple files instead of listing out each individual checkno-errors.ts
that exports a list of files for this fixtureerrors.ts
as of yet; may do so in the future thoughReview Notes
I double-checked that the
transform
hook could be async in the minimum Rollup version we support.v1.18.0
as I couldn't find a mention of async in theCHANGELOG.md
.This could be considered "breaking", but the bundle ordering should realistically not affect anyone (only tests that rely on ordering, which was never guaranteed by Rollup as
this.load
could be called by any plugin at any time) and this should only be additive, in that it increases the number of files that are type-checked / generated declarations for.Related to that, I specifically did not touch the "missed" type-checking / declaration generation that uses
parsedConfig.fileNames
to partly workaround this issue (i.e. #345 and the respective declaration generation block)tsc
will process those. Not processingparsedConfig.fileNames
would mean only processing the Rollupinput
, acting as if thetsconfig
hadfiles
with only that single file from the Rollupinput
in it. That behavior could make sense to some, but not others, so I'm not sure that that's ideal. The "Note" in #345 mentions how users may useinclude
globs orfiles
arrays to list other files they want type-checking and declarations. These files may not be considered part of the Rollup "bundle" however, so I could see an argument for either direction.References
This also fixes various downstream issues:
and probably (hard to tell without more details from issue author):