lint checking is slow for considerably big projects
See original GitHub issueember-template-lint
(v1.0.0-beta.1
) is running for a long time compared to previous versions (before using globby
). After introducing globby
, I can sense the delay very well.
I tried with earlier version (0.7.6), there was no lag. However, I can’t reproduce using a fresh repo 😦
Deps:
"ember-cli": "3.4.3"
"ember-source": "3.4.1"
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Lint Performance Tips - Google Groups
Lint tends to get slower for every release. There's a reason for that: It keeps checking more and more things (as of 3.3...
Read more >Performance Tuning - Google Samples
Performance Tuning. Lint tends to get slower for every release. There's a reason for that: It keeps checking more and more things (as...
Read more >Is it just me or rust-analyzer is unreliable/slow? - Reddit
R-a can be resource intensive, but it's definitely possible to use r-a in large, complex projects without it being slow. Some tips:.
Read more >Which eslint rules in my config are slow? - Stack Overflow
On the project I'm currently working on, combining both eslint_d and --cache brought the linting time from 4+ seconds to 0.17! Share.
Read more >Speeding Up ESLint - Medium
ESLint is pretty slow, especially after adding a bunch of plugins. Today, I happened to notice that on my project of 8 files,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I believe #607 fixed this as well. Not seeing the slowness after upgrading to v1.1.0 that was released just a couple of days ago.
Is there any update on this issue? It’s currently a definite blocker from upgrading large projects to
1.0.0
(beta 6, as of this writing).Here’s my report from upgrade attempt:
I’m using following NPM script for linting all templates in the project:
I’m perfectly fine with this, and never felt the need for
.gitignore
patterns to be taken into account. This should apply to almost all Ember projects. With needs of the rest easily solved by passing more-customized glob string as CLI executable param.Here’s analogous issue I’ve found in ESLint arguing against parsing of
.gitignore
: https://github.com/eslint/eslint/issues/5848 .Digressing from this, some numbers from real-life project:
globby
(0.8.23):npm run lint:hbs 3,19s user 0,14s system 132% cpu 2,519 total
globby
(1.0.0beta6):npm run lint:hbs 77,29s user 28,07s system 112% cpu 1:33,86 total
globby
(0.8.23):ember-template-lint app/pods/application/template.hbs 0,14s user 0,02s system 108% cpu 0,154 total
globby
(1.0.0beta6):ember-template-lint app/pods/application/template.hbs 2,68s user 1,43s system 112% cpu 3,642 total
That’s with Ember
3.3.0
and “fresh”tmp
folder (rm -r tmp && ember server
).Before I did this, linting one file with
globby
took over 20s. Linting whole project took forever (I gave up after waiting around 5-10 minutes). That’s on i9 machine. Over 20s for single file 🙂 .Bottom line: if it’s not possible to quickly find other solution, can we revert https://github.com/ember-template-lint/ember-template-lint/pull/459 until this problem is sorted out upstream? I take ignoring
.gitignore
over this sort of performance degradation, any day.