Skip to content
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

chore: Speed up lint-staged #14896

Merged
merged 7 commits into from Sep 1, 2022
Merged

Conversation

liuxingbaoyu
Copy link
Member

@liuxingbaoyu liuxingbaoyu commented Aug 31, 2022

Q                       A
License MIT

Even without any caching, submitting a JS file was able to drop from 8.3 seconds to 2.6 seconds.

@babel-bot
Copy link
Collaborator

babel-bot commented Aug 31, 2022

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/52853/

@liuxingbaoyu
Copy link
Member Author

Also I found that an overly complex babel.config caused babel-core to start very slowly, with two seconds spent loading the config when lint in our repository.
I think we can improve this in the future by increasing the speed or adding more hints.
For example, to allow output of plugin load times, or to add the expected caller option, allowing the user to pass in ["*"] or ["caller1","caller2"], otherwise output a prompt to let the user notice .

yarn lint-staged
# Specifying `config` manually avoids `lint-staged` scanning the entire repository, even `package.json` containing test suites.
# Use `--no-stash` to skip backup files as we don't automatically fix lint errors.
./node_modules/.bin/lint-staged --config package.json --no-stash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
./node_modules/.bin/lint-staged --config package.json --no-stash
yarn lint-staged --config package.json --no-stash

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS F:\babel> Measure-Command {yarn lint-staged}  

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 773
Ticks             : 27731558
TotalDays         : 3.20967106481481E-05
TotalHours        : 0.000770321055555556
TotalMinutes      : 0.0462192633333333
TotalSeconds      : 2.7731558
TotalMilliseconds : 2773.1558


PS F:\babel> Measure-Command {./node_modules/.bin/lint-staged}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 454
Ticks             : 4540090
TotalDays         : 5.2547337962963E-06
TotalHours        : 0.000126113611111111
TotalMinutes      : 0.00756681666666667
TotalSeconds      : 0.454009
TotalMilliseconds : 454.009

yarn adds an extra 2s, which I tend to avoid.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh ok. I'm surprised that it's this slow just to load a script.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this seems to be brought by yarn3, which creates a new virtual environment for all commands.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI here is my benchmark results

time yarn lint-staged
→ No staged files found.
yarn lint-staged  0.62s user 0.10s system 114% cpu 0.634 total

time ./node_modules/.bin/lint-staged
→ No staged files found.
./node_modules/.bin/lint-staged  0.17s user 0.04s system 70% cpu 0.285 total

I am good either way if the startup time is less than 1 sec, but the Windows platform performance is a bit annoying. Maybe yarn PnP will save us some time here? /cc @merceyz

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merge it first?

Copy link
Contributor

@merceyz merceyz Sep 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JLHwung If the startup time in this case is just Yarn it probably wont help, we are aware of the issue though.
Ref yarnpkg/berry#2575

babel.config.js Outdated Show resolved Hide resolved
babel.config.js Outdated Show resolved Hide resolved
liuxingbaoyu and others added 2 commits September 1, 2022 01:46
Co-authored-by: Nicolò Ribaudo <nicolo.ribaudo@gmail.com>
babel.config.js Outdated
@@ -304,13 +304,30 @@ module.exports = function (api) {
config.plugins.push("babel-plugin-istanbul");
}

if (api.caller(caller => caller && caller.name == "@babel/eslint-parser")) {
// We disable all the plugins and presets, since we are only interested in parsing JS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of caller detection in Babel config, can we disable the whole Babel config loading in

?

See also https://github.com/babel/babel/tree/main/eslint/babel-eslint-parser#additional-parser-configuration

@JLHwung JLHwung merged commit 2a9aabc into babel:main Sep 1, 2022
@github-actions github-actions bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Dec 2, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants