OS X Sierra
@angular/cli: 1.0.0-beta.31
node: 6.9.1
os: darwin x64
@angular/cli: 1.0.0-beta.31
@angular/common: 2.4.7
@angular/compiler: 2.4.7
@angular/core: 2.4.7
@angular/forms: 2.4.7
@angular/http: 2.4.7
@angular/platform-browser: 2.4.7
@angular/platform-browser-dynamic: 2.4.7
@angular/router: 3.4.7
@angular/compiler-cli: 2.4.7
Using a reasonably large repo with these package.json scripts:
"lint": "ng lint",
"tslint": "tslint \"src/**/*.ts\"",
I get the following runtimes:
iDevBook01:console jr$ time npm run tslint
> [email protected] tslint /Users/jr/dev/console/console
> tslint "src/**/*.ts"
no-unused-variable is deprecated. Use the tsc compiler options --noUnusedParameters and --noUnusedLocals instead.
real 0m16.808s
user 0m17.005s
sys 0m0.748s
iDevBook01:console jr$ time npm run lint
> [email protected] lint /Users/jr/dev/console/console
> ng lint
no-unused-variable is deprecated. Use the tsc compiler options --noUnusedParameters and --noUnusedLocals instead.
All files pass linting.
real 1m49.394s
user 1m49.213s
sys 0m1.437s
I have no idea why ng lint should take so absurdly long compared to vanilla tslint. I'm using the standard tslint.json generated by ng init and "codelyzer": "^2.0.0" (also tried with 2.0.0-beta.4, no change).
Any idea where the difference comes from? Any input I can provide to debug this?
Type checking is enabled in the ng variant.
EDIT:
As a clarification, what is actually enabled is type info collection. Type checking and type error reporting is not actually enabled.
Don't I get type checking for free from tsc when compiling anyway?
Am 13.02.2017 22:41 schrieb "clydin" notifications@github.com:
Type checking is enabled in the ng variant.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/4675#issuecomment-279531480,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH8N2r6HCUl6-6JbdH3H09eD_vgU4Uuks5rcM4AgaJpZM4L_u-y
.
There's additional lint rules (not include by default) that require type information.
However, If you remove the "project" setting from angular-cli.json and use just the files setting, you should get the same behavior as the tslint command you used. If there is still a large variance we can investigate further.
Removing the "project" setting from the "lint" section of angular-cli.json results in this error:
$ ng lint
Path must be a string. Received undefined
TypeError: Path must be a string. Received undefined
at assertPath (path.js:7:11)
at Object.dirname (path.js:1324:5)
at Function.Linter.createProgram (/home/vagrant/ng2-widgets/node_modules/tslint/lib/linter.js:55:37)
at lintConfigs.forEach (/home/vagrant/ng2-widgets/node_modules/@angular/cli/tasks/lint.js:28:36)
at Array.forEach (native)
at Class.run (/home/vagrant/ng2-widgets/node_modules/@angular/cli/tasks/lint.js:27:14)
at Class.run (/home/vagrant/ng2-widgets/node_modules/@angular/cli/commands/lint.js:20:25)
at Class.<anonymous> (/home/vagrant/ng2-widgets/node_modules/@angular/cli/ember-cli/lib/models/command.js:134:17)
at process._tickCallback (internal/process/next_tick.js:103:7)
This is a real issue. I tried running tslint with the angular-cli tsconfig.json and it is still 2 times faster then running ng lint.
See the timings below:
time tslint --project src/tsconfig.json
real 0m2.091s
user 0m2.616s
sys 0m0.132s
time tslint src/**/*.ts --project src/tsconfig.json
real 0m1.827s
user 0m2.228s
sys 0m0.088s
time tslint src/**/*.ts
real 0m1.347s
user 0m1.444s
sys 0m0.084s
time ng lint
All files pass linting.
real 0m4.241s
user 0m5.220s
sys 0m0.168s
I'm running it on an empty newly generated project using angular-cli master commit 469ca912dc8
@Luftzig I wonder if you are not missing the tslint.json configuration (that activates the codelyzer rules which could more time).
Also note that ng lint currently runs against the app, test, and e2e elements of the project.
Heya, is such a big descrepancy still a thing?
It should be slower than running tslint once directly because, as @clydin said, ng lint runs tslint once for each 'project'.
But I think there was a bug that made it not ignore node_modules and that's fixed now.
@filipesilva I don't know about the performance problem but the node_modules is still not ignored with 1.0.0-rc1… you have to explicitly ignore it the .angular-cli.json configuration file.
@filipesilva if you have the time to try, you can always experiment with a project like the one I'm working on (https://gitlab.com/linagora/petals-cockpit, run ng lint from the frontend directory) and compare with the tslint timings. There is a big difference:
$ time (tslint --project src/tsconfig.app.json --exclude "**/node_modules/**" && tslint --project e2e/tsconfig.e2e.json && tslint --project src/tsconfig.spec.json)
( tslint --project src/tsconfig.app.json --exclude "**/node_modules/**" && ) 13,80s user 0,47s system 122% cpu 11,604 total
$ time ng lint
All files pass linting.
ng lint 26,58s user 0,30s system 106% cpu 25,280 total
Taking two times longer is still within the expected range due to the type checking that @clydin mentioned in https://github.com/angular/angular-cli/issues/4675#issuecomment-279544636.
Not ignoring node_modules by default is not intended however. Will investigate.
@victornoel I looked further into this, and as far as I can tell you only need to exclude node_modules if you are importing a library that published it's TS files (which is bad practice) and you are importing them.
This is a case where I think one should exclude it manually. There are TS rules that need type-checking information so it makes sense to default to checking them.
See more about this in @delasteve's post in https://github.com/angular/angular-cli/issues/4350#issuecomment-277573957.
node_modules in and of itself is not included by default:
kamik@T460p MINGW64 /d/sandbox/master-project (master)
$ cat src/lint.ts
"a"
kamik@T460p MINGW64 /d/sandbox/master-project (master)
$ cat node_modules/lint.1.ts
"a"
kamik@T460p MINGW64 /d/sandbox/master-project (master)
$ ng lint
src/lint.ts[1, 1]: " should be '
src/lint.ts[1, 4]: Missing semicolon
Lint errors found in the listed files.
@filipesilva thanks for detailed explanation :)
@filipesilva a quick question, why is this a bad practice to include the ts file in the published artefact and is there some source for this assertion? The author of a library that publishes ts files is asking me this question :)
@victornoel generally it's discouraged to ship TypeScript with third party libraries because it would require the consumer to replicate the complete build environment of the library. Not only typings, but potentially a specific version of ngc as well.
Publishing plain JavaScript with typings and meta data allows the consuming application to remain agnostic of the library's build environment.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
@filipesilva if you have the time to try, you can always experiment with a project like the one I'm working on (https://gitlab.com/linagora/petals-cockpit, run ng lint from the
frontenddirectory) and compare with the tslint timings. There is a big difference: