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

Named tasks in config #410

Closed
jthegedus opened this issue Mar 11, 2018 · 5 comments
Closed

Named tasks in config #410

jthegedus opened this issue Mar 11, 2018 · 5 comments

Comments

@jthegedus
Copy link

jthegedus commented Mar 11, 2018

Description

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.

@sudo-suhas
Copy link
Collaborator

@jthegedus We too have been contemplating changing the config schema to allow specifying ignore patterns and a command template among other things. So this is something we might be able to address in the next major version.

Using Chalk to colour the output would also help here.

Those messages come from listr so probably not much we can do here.

@jthegedus
Copy link
Author

@sudo-suhas I'll keep my eyes open for that update 😃 If this request is tracked elsewhere for that release, feel free to close this issue 👍

@gvincentlh
Copy link

Bump. We could really use this feature (naming of tasks).

@okonet
Copy link
Collaborator

okonet commented Sep 14, 2018

Those messages come from listr so probably not much we can do here.

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.

@okonet
Copy link
Collaborator

okonet commented Jul 6, 2019

For now the decision is not to implement this and use custom scripts task in the package.json for that purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants