-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin not respecting include
/ exclude
when generating declarations
#162
Comments
On a run with verbosity > 1, do you see plugin printing Those entries are for all root files that are getting transpiled. They are controlled by both include/exclude in plugin options and include/exclude in tsconfig. Build process looks something like that:
Files found through tsconfig should show up in
Since you have You are also likely being hit by #148 (Compilation very slow with TS v3.4) |
Hmm, okay so seems likely that some combination of tsconfig and rpt2 handling is causing the extra work. The fileNames array contains, for me, every single javascript file in the repository, not counting the actual build directory where the build is happening but that is understandable since there is the single "*" path mentioned. That is some 352 JS files. verbosity === 2 gives me the following kind of log:
ad nauseum. Interspeded there is a single "transpiling" message which is expected since a single TS entry file is included in this repository. So it seems that the problem is that rpt2 finds all of my JavaScript based on the "*" rule and then proceeds to create declarations for every single file on every single build. Or at least it does something quite time consuming on every single build. I guess this sort of begs the question if declaration generation for all files from tsconfig is necessary? Or should the paths only be used to guide imports found from transpiled / processed modules? EDIT: Removing the "*" rule did not change the slowness so I guess the fileNames is just based on include / exclude in tsconfig. |
Switching to I'm relatively sure this is not really how the plugin should work. If this were TypeScript working inside eg. Visual Studio Code then I'd expect that every file gets cataloged and their declaration generated (although even that would probably be done at a lower priority if they're not currently open / imported by an open file). However, with Rollup I don't think TS (or the plugin, mostly) should care about every file that is available in the system. It should only concern itself with those files that it receives from Rollup as well as modules imported from that file. And of course here the tsconfig includes / excludes and paths should come into play. Or at the very least I don't think that the plugin should be combing through the available modules if it is not going to do anything anyway. |
After you set Plugin will print 'transpiling' entry for every file it actually transpiles, and it will print 'writing declarations` entry for every declaration it generates (you will have to up verbosity to 3 to see those though). If it doesn't print anything then it doesn't process that file directly. Typescript might be looking at those files internally if they get imported, but that's out of my control (but will be minimized by |
Are you running it in watch mode btw? Why does it do 8 builds in that log you posted above? |
Watch mode is not used. The reason for the multitude of builds is mentioned in the original comment: The build system in question consists of tens of individual files which are built one by one using rollup. The 8 outputs you see are each one of those build steps. Here is an example of what I believe to be just a single file being built: log:
Why I think this is one file (and not two files) is that the file3.js there is in the "src" folder which I've expressly blacklisted from appearing as entry files. So I'm not, myself, ever calling rollup with that file as the input file. The output of the plugin always hangs before the I'm definitely not an expert and know unfortunately little about how Rollup plugins truly work. That said, it does seem excessive to me that rpt2 is running on and even resolving seemingly all imports from at least the given entry file, even though that entry file is Or is this simply that the plugin is starting up on build start regardless of the entry file type? |
Looks like in this run you didn't have any typescript files, so nothing was transpiled (unless there were more lines in that log). We can't avoid resolving js files imported from ts files because we need to resolve it to know it is a js file. But I suppose rpt2 shouldn't be trying to resolve imports for modules it didn't transpile itself in the first place. That might kill another use case of importing ts files directly from js files and having them transpiled on the fly, I'll have to check if that is even possible. |
Yeah, in this case there actually were no TS files at all. Which is pretty much why I believed something to be amiss in the first place: No TS files are present, the plugin is set in the plugin chain just in case there are. Yet, the build times absolutely exploded. (Although, there still are some hundred files that I cut from the log. I figured you don't really want to see that :) ) This is definitely a bit of a convoluted problem. Personally, in my use case, I dislike rpt2 doing any of the resolving so far as it does not pertain to TS files importing other files, or JS files importing TS files. Even TS files importing eg. "lodash" to node modules on its own is something I do not like since, in my case, I don't want to allow these sorts of imports. Yet, I am using rpt2 with the idea that if someone has imported "lodash" and "@types/lodash" is installed, then the type checking should work (although the person who did this should be given a talking to)... So yeah, I'm sorry. I have a really dumb system on my hands :D So far as I am concerned, importing TS files from JS files should work. TypeScript, I believe, does support this with Which, in the end, is what you're already doing. I presume that the problem is just that you're using the TS resolver, especially on imports from files that are not actually TypeScript. The TS resolver seems to take an unacceptably long time. So far as it comes to resolving logic within a given Rollup build, that including rpt2 changes the resolving logic from standard Rollup (only relative paths are resolved, When rpt2 is type checking a TS file, then I would expect the TS resolver to be used since ambient types as well as types inferred from JS files are relevant to the type validity of the file. But even then actual transpiling of the file I would expect to just consist of removing the TS and returning plain JS. Sorry, this is probably getting way out of scope. |
Try with current master, plugin should not be resolving random stuff now. |
In 0.23.0 now |
Awesome. I'll try and get around to testing this one of these days. |
include
/ exclude
include
/ exclude
include
/ exclude
when generating declarations
What happens and why it is wrong
I have a directory within which various entry files are sought based on their file paths. These entry files are then one by one (not as an array of input files) built using Rollup. As some of these files may be TS files or may import TS files, I wanted to use rollup-plugin-typescript2 to type check and build these files.
However, after adding the plugin to the rollup config with only
.ts
and.tsx
files included, build times jump massively. At the same time JavaScript files which import eg. lodash with the intention that Rollup will warn me of these modules being taken as external since I'm not using rollup-plugin-node-resolve (intentional, again) start appearing in the bundling and give errors for being CJS and thus not exporting anything. That is to say that clearly this plugin is resolving those imports even in normal JavaScript files and happily transpiling or at least analyzing these JavaScript files for types. This despite me explicitly only including TS files and explicitly excluding non-TS files.Versions
rollup.config.js
tsconfig.json
plugin output with verbosity 3
log:
The text was updated successfully, but these errors were encountered: