-
-
Notifications
You must be signed in to change notification settings - Fork 243
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
Extremely high compilation time for production build on v5 #453
Comments
Thank you for reporting this issue. Starting from version 5, eslint has its own process, separate from typescript checker. It means that eslint configuration should not affect typescript check time (except IO as the file system is shared) and vice versa. It can slow down the time to show issues as it uses Currently, we don't have implemented profiling for vue extension and for eslint. I can add it - maybe it would help you to find the issue. Also, I think there is lack of documentation on how to set up eslint for .vue files. By default, the plugin sets:
which doesn't include |
Consider that the problem isn't probably related to ESLint. That let apart, I think I tried the linter with Vue files and I seem to recall that it worked anyway (probably because it got up the eslint configuration). After a lot of trial and errors, I noticed that removing some ts aliases solved the issues. Gonna study a bit what's happening there and what do they have in common EDIT: tried to add |
Cool, thanks for digging into this 👏 I would like to help, but it's hard without a reproduction repository. You can clone the plugin repository and add I have to admit that we don't have end-to-end tests for .vue linting. The assumption is that eslint linter should be capable of doing everything that |
I added a new edit on previous message: seems like I was doing something wrong in tsconfig, Vue linting works as expected even without the extension options you mentioned. Right now, I managed to make my project work (and it's blazing fast!) with this configuration: {
"extends": "@quasar/app/tsconfig-preset",
"compilerOptions": {
"baseUrl": ".",
"paths": {
"src/*": ["src/*"],
"app/*": ["*"],
// "components/*": ["src/components/*"],
// "layouts/*": ["src/layouts/*"],
// "pages/*": ["src/pages/*"],
"assets/*": ["src/assets/*"],
"boot/*": ["src/boot/*"]
}
}
} We're gonna release q/app v2 (which will support this package both v4 and v5) and try to gather more examples on the wild to pinpoint the issue. Gonna try what you suggested next week. If this could ring some bell to you, our current investigative trail (lol) brought us to Example: const routes: RouteConfig[] = [
{
path: '/',
redirect: () => ({ name: isAuthenticated() ? 'home' : 'login' })
},
{
path: '/',
component: () => import('layouts/guest.vue'),
beforeEnter: redirectIfAuthenticated,
children: [
{
path: 'login',
name: 'login',
component: () => import('pages/login.vue')
},
{
path: 'forgot-credentials',
name: 'forgot-credentials',
component: () => import('pages/forgot-credentials.vue')
}
]
},
{
path: '/',
component: () => import('layouts/authenticated.vue'),
beforeEnter: redirectIfGuest,
children: [
{ path: 'home', name: 'home', component: () => import('pages/home.vue') },
{
path: 'statistics',
name: 'statistics',
component: () => import('pages/statistics.vue')
},
{
path: 'registry',
name: 'registry',
component: () => import('pages/registry.vue')
},
{
path: 'administration',
name: 'administration',
component: () => import('pages/administration.vue'),
beforeEnter(to, from, next) {
if (!isAdmin()) {
next(false);
} else {
next();
}
}
}
]
}
]; |
Hmm... Hard to tell if dynamic imports can be an issue. We use standard TypeScript API, with a custom
|
Liked the proposal 👍 I don't think it's about |
I'm hijacking this issue but wanted to say: this ☝️ |
Would you like to submit a PR? |
Finally got little time to come back at this. I see you added some items to the time stats, here what do I get now with
and
Will continue my debugging next week and let you know if I discover something new |
Some comments on DX:
I tried to add a Vue-related performance measurements, but seems like I'm missing something obvious:
Meanwhile I enabled all diagnostic options like this typescript: {
extensions: {
vue: true
},
diagnosticOptions: {
syntactic: true,
semantic: true,
declaration: true,
global: true
},
profile: true
},
eslint: {
files: './**/*.{ts,js,vue}'
},
logger: {
infrastructure: 'console'
} and got
I cannot find some marks name in the codebase ( Any idea on how to proceed further? |
I'm exploring TS perf issues world, seems there are quite a bit slowdown problems around.
It may be something related to Quasar types? Does this ring any bell? Running |
Fascinating - I hadn't heard of "Quasar types" |
I mean, Quasar Framework typings:
(Or was it some pun I didn't get 🤔 ) |
More specific question: any idea on how I can start profiling TS stuff while is being processed by the plugin (or before, or after, anything), both in v4 and v5? |
Although it's primitive - simply hacking in |
Hi team, new ForkTsCheckerWebpackPlugin({
typescript: {
enabled: true,
configFile: 'tsconfig.json',
build: true,
mode: 'readonly',
diagnosticsOptions: false,
compilerOptions: {
skipLibCheck: true,
}
},
eslint: {
enabled: production ? false : true,
files: './src/**/*',
},
}) [...100s of...]
ERROR in src/views/[...]/index.scss
[unknown]: Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: src/views/[...]/index.scss.
The extension for the file (.scss) is non-standard. You should add "parserOptions.extraFileExtensions" to your config. |
On Quasar framework part, we decided to wait a bit to see if someone else bump into this, as I'm just running in circles when trying to debug this problem and we must focus on some other features. |
Just wanted to chime in and bump this. This plugin seemed fine on 5.2.0 for a while till my own project grew, and then some kind of threshold occurred and it exploded in compile time. Seems related to MobxStateTree & MaterialUI, which are known for their complex types.
Seems related to MobxStateTree & MaterialUI, which are known for their complex types. Would be ideal to see if [email protected]'s extended perf profiling features can be integrated here to map long |
We use the same API as the |
@piotr-oles have you looked into supporting microsoft/TypeScript#40124 4.1.0's new profiling outputs? More info here microsoft/TypeScript#40063 A projects file paths could be mapped to the types.json/trace.json output, then rendered as a ordered list or tree based on costs. Might even make sense to emit a warning based on a threshold for type resolution time to let the user know when a new dependency or interface has a large impact. |
@nfour I've added a support for "generateTrace" in 6.0.0-alpha.2 :) |
Good! We're working on Quasar v2 (with Vue3 support) which means we'll have to migrate to 5+ version of fork-ts-checker. |
https://github.com/nfour/ts-rank whipped this up to quickly parse generateTrace and show some useful numbers. Still early tho but I've used it to fix some perf issues already. |
For my setup this slow down seems to mainly come from eslint, I guess it doesn't work fine with webpack 5's cache.
|
@IlCallo The newest TypeScript Beta version contains a fix that could potentially address some of these performance issues. Could you test it? |
Hey there, you mean TS 4.3 beta? What fix in particular should be useful in our case? Also, with are in the verge of releasing Quasar v2 (and Will try to finish my project migration to Quasar v2 and try it out again |
The fix: microsoft/TypeScript#43314 :) |
@piotr-oles @johnnyreilly , is the latest version of fork-ts-checker-webpack-plugin compatible with webpack 5 ? |
yes, we have e2e tests that uses webpack 5 |
I believe that this is related #612 |
I cannot reproduce anymore the problem after migrating to Quasar v2, which uses Webpack5 and latest version of this package |
Current behavior
We are about to release Quasar Framework CLI v2 (
@quasar/app
), and really want to integrate fork-ts-checker new version.We are testing it on real world (private) projects and I noticed an extreme (talking about some minutes, 18s vs 183s) slowdown of production compilation in a particular scenario, for which I cannot pin-point the cause.
I could use some guidance, because the behaviour I'm experiencing is pretty random and don't know how do debug it further.
Right now my instinct tells me there is something wrong with our configuration of v5 and the tsconfig.json file, probably because we add and configure the plugin into
@quasar/app
and not into a webpack config file into the project root.Or some kind of incompatibility with@typescript-eslint
pre v3EDIT: nope, upgraded to v3 and problem persist. Also, clean test project didn't had problems with pre v3
Enabling
typescript.profile
using the only configuration which avoids the slowdown (see below) produce no output.Enabling
typescript.profile
when the problem is present I got thisReverting to
v4.1.6
fixes the problem, so I'm fairly sure the problem is in the new major version (or our configuration).This is how we internally enable TS support into the Quasar webpack chain: https://github.com/quasarframework/quasar/blob/9133883bb3f2a3764b697bad8ffc5e313502c4ea/app/lib/webpack/create-chain.js#L154-L182
Notice we always include vue ts support into the options via webpack chain as
In Quasar configuration we allow the user to customize your plugin options like
Into our starter kit we automatically setup the configuration depending on initial user choices: https://github.com/quasarframework/quasar-starter-kit/blob/19bd2ec30086d1086b7e44929bed71273d3d41a4/template/quasar.conf.js#L26-L33
Experiments till now
supportTS: true
With no eslint configuration, the problem persist
With eslint enabled and this
eslint.files
glob patterns the problem is solved but I get the error below error, no lint error is displayed for Vue and TS files andtypescript.profile
output is not shown.All this stuff makes me think nothing is actually being processed and that's why there's no slowdown.
With eslint enabled and this
eslint.files
glob patterns the problem persist and I get an error for any extension@typescript-eslint
cannot process and for all Vue files.This last bit is strange, because Vue files are marked to be processed.
One more point on the "there's something strange with tsconfig.json" path.
Ex.
With eslint enabled and this
eslint.files
glob patterns the problem persist.Miscellaneous info
The project tsconfig is in the project root folder and extends the preset provided by Quasar (https://github.com/quasarframework/quasar/blob/dev/app/tsconfig-preset.json)
I'm using Vue Composition API package (v0.5 right now), but the clean Quasar project I created uses it too and doesn't seems to be affected.
Expected behavior
Avoid slowdown.
Steps to reproduce the issue
I'm not able to replicate the problem with a fresh Quasar project using latest unreleased packages and starter kit.
Environment
The text was updated successfully, but these errors were encountered: