Compilation very slow with TS v3.4 #148
Comments
|
I'm having the same issue. Went from |
|
I tried to reproduce and at first I saw a slowdown, but using Could you set |
|
@ezolenko Sorry for the late reply! I put TS 3.3.3333 TS 3.3.4000 TS 3.4.1 TS 3.4.3 Additionally there is this issue on the TS repo which seems related but I have Let me know if you need more infos. For fun I also tried the latest TS 3.5.0-dev.20190413 |
|
That issue you found (microsoft/TypeScript#30663) and the fact that 3.5-dev became 5 times faster for you makes me think they did something with Your project might be using affected type structures elsewhere, that's why pinning I guess we'll wait for final 3.5 release. |
|
btw, try building with |
|
Has anyone confirmed if this is this fixed with 3.5 release? |
|
@tomasro27 Not for me, nor with 6 ( |
|
It looks like 3.5 is a little bit faster but it could still be better |
|
Is there any update on this? Seem like its still blocked by TS? |
|
Yeah, I don't think anything can be done from this end. Anybody is welcome to try though :) |
|
+1 |
|
But the problem is that it doesn't give any compilation error (if you use vscode, it'll prompt the errors 😄). At least I can do |
|
@ezolenko do you know what exact typescript api call causes the build to slow down? :) |
|
@ZainlessBrombie no, everything I know is in this thread. Typescript issue that is linked is probably related, but not direct cause (because they say it should be fixed in 3.5+, and apparently it isn't). If you have slow builds in your project, check if ts 3.3 is actually faster if possible, maybe the problem is not typescript, but something else. |
|
Alright thanks. If I get around to it this might be a wall I'm willing to bash my head against so to speak :) Edit: This problem only occurs for files that import styled components as it seems |
|
Profiling typescript reveals the source of the problem to be these extremely large unions that styled components has. The only place to fix this is typescript, unless there is a way to get typescript to cache module resolution (which it should). |
|
I'm actually not using module resolution cache in nodeModuleNameResolver call here: rollup-plugin-typescript2/src/index.ts Line 148 in b7c7389 Not sure if that makes ts use default one or not use one at all. |
|
Yes I saw that TODO :) |
|
I am currently in the process of migrating my C# codebase of my library to TypeScript and I'm using Rollup for bundling. (I had a custom C# > Haxe > JavaScript toolchain before). Unfortunately I am suffering also quite a lot on the compilation speed of my new TypeScript codebase which makes development quite hard. If possible I am happy to provide some profiling reports if it is possible to generate them. Here some insights to my project: Usually I'm using ttypescript to do to some AST transformation. rollup -c rollup.config.ts: ~9-10sec tsc --version: 3.8.3 ttsc --version: 3.8.3 Incremental builds are active in the tsconfig. It seems to me quite unusual that an incremental/watch build would take twice as much than a full build. Things seem to go crazy in my environment when ti comes to testing. I hooked up rollup with karma and this typescript plugin. As you might know: each test suite gets its own bundle, which means the numbers of above pile up. Memory grows to >2GB over time; even after minutes the test run does not actually start. This happens on each single Once it reaches the "Generating bundle for..." area on the test generation I see ridiculous high numbers: I have no clue where this issue might be caused and if it is really due to the typescript module of rollup but this seemed to be the most likely issue I'm related to. As my repo is quite large and complicated I did not share more details on configs. If anybody can guide me how to collect them, I'm happy to provide logs/profiling results etc. I will try to setup a new simple independent repository reflecting my overall project situation, but I cannot promise that the issue will persist. |
|
@Danielku15 Your main problem is that you are migrating from C# and not from C++ :) This plugin is not explicitly using typescript's own incremental builds (this didn't exist when it started). You could try Another option is to do typescript compilation out of rollup chain (as a prebuild step in npm or something) and feed resulting js to rollup instead. Watch build would be interesting, although I think you can start tsc and rollup in watch mode and if project is configured correctly it will just work. |
Off-Topic: I am not sure if I would like to migrate a C++ framework/library to TypeScript. Depending on the use of macros and templates (which C++ devs tend to love) things might go wild during migration 😅 Luckily my C# codebase was always tailored to a style that allows cross compilation to other languages so the result is quite acceptable from a code structure. I just need to figure out a bit better how to organize the modules to reduce some overhead. 😊
This is interesting, is this plugin having some own custom "incremental" build strategy? This could explain why a full-clean build might be taking longer than an source change when using watch. The typescript compilation is more or less stable, it is unfortunate that this plugin cannot utilize the incremental updates yet, but I think the time spent in the type script compiler is stable. But the time spend in rollup seems to be varying. Only this explains to me that a clean build is faster than a code change with watch-mode.
Thanks for the hint I will give it a try to see if it improves.
I had such a setup at the very beginning but dropped it half way to have "watch" builds during development. I will give it again a shot if I can hook up a pipeline with the two tools "watching" independently. 👍 Update 1: I was able to setup my whole compile and test environment now with invoking tsc chained with rollup. I needed to make my own rollup plugin to resolve the tsconfig paths correctly but after that it was working fine. Clean compilation: 9secs, Watch compilation: 0.5-1secs and tests via Karma + Rollup are also running (compilation there takes a bit longer as it generates a bundle for each test suite). |
Where do I have to add this? rollup.config or tsconfig? |
|
The bitter truth now is that you should use esbuild plugin instead of this one. And if you want a type checking you just need to run |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Yep, sorry, for producing P.S. There is Vue 2 plugin for Vite. |
It's important to note that even though esbuild is dope you will sacrifice some rather essential TypeScript features. Like for one, const enums are not supported plus a couple of other caveats. Another rather important feature that is lacking if one would choose to adopt the esbuild plugin into their stack will be the inability to elegantly handle TypeScript As per issue 70, rollup-plugin-esbuild requires you lean on @rollup/plugin-alias for handling remaps which is far from ideal. This becomes rather problematic in large projects that take advantage of import remaps because @rollup/plugin-alias is slow, verbose and requires you to explicitly define the entries and thus those speed gains made with esbuild are quickly taken away. If you decide to choose the official @rollup/typescript plugin then be rest assured at some point you will run into issues and find yourself trying to debug something that will be directly related to that plugin. Given the rather incorrigible nature some official rollup plugin maintainers happen to retain - when (and trust me, it is a matter of when) you find yourself scouring previous issues of the official plugins repository in an attempt to fix whatever the problem you've encountered might be or even if you wish to submit a PR it will be met with red-tape and fatigue. Essentially, the juice is really not worth the squeeze on that one imo. There is also tszip maintained by ctjlewis which might be a solution for some as it is using a The fact remains that ts2 is clearly the breadwinner in the nexus of Rollup and TS support. It is not the fastest solution but it is the most stable and well maintained (side note: thanks ezolenko). There are some things you can do to help negate that, like those mentioned in previous comments here and while I am not sure if applicable maybe Wishing everyone good karma, heath and happiness! |
|
For anyone else coming to this issue after finding rollup builds were intolerably (25 minutes for a large project) our solution after some investigation was rather simple. Setting |
agilgur5
added
scope: upstream
agilgur5
added
solution: tsc behavior
upstream issueHi folks, just doing some housekeeping in the issues. I'm going to close this one out as it's gone quite stale (no comments in 9 months) and as far as I can tell, there really isn't anything we can do on this front since the slowdown is within TypeScript itself and not this plugin. rpt2 also does not specify a specific version of TS and is compatible with many versions (we only specify a minimum TS version). This issue with TS v3.4 was also reproduced by other tools in TS ecosystem, e.g. s-panferov/awesome-typescript-loader#633 . So it's not specific to this plugin either (or even Rollup) in that sense. rpt2 internal nuancesI've made a handful of optimizations here and there since I joined on to help maintain rpt2, but most of those have been cache or watch mode related. The CPU-bound nature of compilation and type-checking still remains and those are primarily just calls to the TS Compiler API, so there isn't much speed-up to be had there. We use the Rollup also processes the code graph on a file-by-file basis, so file-oriented APIs are somewhat necessary for us to use. If we offload type-checking to another thread, as #113 suggests, then it might be possible to operate a bit differently in that case. tuningOverall, I don't think there's anything we can do to address this issue specifically. There may be other optimizations to be had in other issues, but this one itself is generic, caused by upstream TS itself, and doesn't really have a course of action we can take. Off the top of my head, a few configurations that can change performance characteristics are: rpt2 options:
Rollup options:
|
What happens and why it is wrong
Once I upgraded TS to v3.4.2, the compilation time is very slow. With TS v3.3 my project built in ~20s and with TS v3.4 it takes ~5mn.
I tried with
clean: true, I tried to addtypescript: require('typescript'), I tried to upgraderollupand all the related plugins.. Each time, same result the compilation takes a lot of time.Note: when I run
tsc -p tsconfig.prod.jsondirectly, it takes less than 10 seconds to output the dist.Environment
Versions
rollup.config.js
tsconfig.json
tsconfig.json
tsconfig.prod.json
package.json
plugin output with verbosity 3
Output
The text was updated successfully, but these errors were encountered: