Named tasks in config
See original GitHub issueDescription
The console output of any underlying tasks is replaced with Running tasks for <pattern>
. It would be nice if I could name each task so other users didn’t have to dive into the config to understand what commands actually runs on each pattern. This is exacerbated in monorepo setup.
EG: instead of a .lint-stagedrc.yml
as such:
"*.{js,jsx,ts,tsx,json,css,scss,md,graphql}":
- prettier --write
- git add
"*.{js,jsx}":
- yarn lint
Writing this:
"format with prettier":
"*.{js,jsx,ts,tsx,json,css,scss,md,graphql}":
- prettier --write
- git add
"eslint":
"*.{js,jsx}":
- yarn lint
"typecheck with Flow":
"*.{js,jsx}":
- yarn glow
would mean the output could be format as such:
↓ format with prettier
✔ matching on *.{js,jsx,ts,tsx,json,css,scss,md,graphql}
↓ eslint
✔ matching on *.{js,jsx}
↓ typecheck with Flow
✔ matching on *.{js,jsx}
This format would allow us to distinguish the same pattern being used in completely different commands (see eslint and typecheck above) instead of outputting a single summary for each pattern.
I understand this conflicts with using objects to determine simple vs advanced configs. I haven’t thought of a nice solution to propose, sorry.
As a side note, that config format is valid as the object keys do not conflict with any of the advanced object keys. As such it runs but does not match any patterns (fair enough). But the output is confusing for anyone who would expect to be able to name tasks, as there’s no grammar separating the result vs the pattern being matched:
↓ Running tasks for format with prettier [skipped]
→ No staged files match format with prettier
↓ Running tasks for eslint [skipped]
→ No staged files match eslint
↓ Running tasks for type check with Flow [skipped]
→ No staged files match type check with Flow
A suggestion here would be to clarify what is/is not a pattern:
↓ Running tasks for pattern: "format with prettier" [skipped]
→ No staged files match pattern: "format with prettier"
Using Chalk to colour the output would also help here.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:4
- Comments:5 (2 by maintainers)
Top GitHub Comments
For now the decision is not to implement this and use custom
scripts
task in thepackage.json
for that purpose.I still think we can use ansi color in there. Something worth trying IMO.
On a general note: I’m not opposed to this if this aligns with #277 so please make a proposal that would fit this goal. Additionally, I would expect someone to work on this since I’m out of capacity of free time anymore.