-
-
Notifications
You must be signed in to change notification settings - Fork 412
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
Consider allowing running of programatic tasks via Node API #1398
Comments
I really like it! Do you want to create a PR for that? @iiroj wdyt? |
Is the functionality essentially the same as creating a separate Node.js script file, and having that be the linter? What benefit is there for defining it directly in the config? It sounds doable, but is a separate pipeline to the existing thing being based on spawning processes with |
To answer myself: one benefit is that file names would be passed directly so there's less need for escaping etc. |
This might be a good use of |
Since we execute the current "function config" functions before running actual tasks and also validate the output to be // lint-staged.config.js
export default {
"*.js": (stagedFiles) => {
return () => lintJsFiles(stagedFiles)
}
} the syntax of the returned functions could be: type TaskFunction = (stagedMatchedFiles: string[]) => Promise<void> but since they're returned from inside a config function, one could of course handle the matched filenames in there as well. what do you think? |
Description
Currently, the signature of a task in lint staged is —
where it always expects a shell command as output that it runs via execa. However, consider adding support for promise returning functions instead. E.g.
Advantages —
yarn
)Given lint-staged is used in steps like pre-commit that need to be lightning quick, saving on shell invocation / yarn invocations costs can be significant. I understand there is value in the declarative nature of the current config — but optimizing for latency in
ms
is an important goal for something that runs in the critical path of dev workflow.If this is allowed, the signature would become —
Where
Promise<void>
can indicate a freeform task.Is this something that sounds interesting to you? Do you see any challenges with this?
The text was updated successfully, but these errors were encountered: