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

Feature request: Add descriptions to tasks #14949

Closed
oscarotero opened this issue Jun 23, 2022 · 14 comments
Closed

Feature request: Add descriptions to tasks #14949

oscarotero opened this issue Jun 23, 2022 · 14 comments
Labels
suggestion suggestions for new features (yet to be agreed) task runner related to deno task

Comments

@oscarotero
Copy link

oscarotero commented Jun 23, 2022

Hi. I think it would be great to include descriptions to deno tasks, and show these descriptions on run deno task. For example, the following tasks:

{
  "tasks": {
    "format": "deno fmt .",
    "lint": "deno lint ."
  }
}

Could be also defined as following:

{
  "tasks": {
    "format": {
      "run": "deno fmt .",
      "description": "Format the code",
    },
    "lint": {
      "run": "deno lint .",
      "description": "Lint the code",
    }
  }
}

And show these descriptions by running deno task:

Available tasks:
  format         Format the code
  lint           Lint the code

The use of objects to define tasks (with run and description properties for now) could be extended in the future with more options (like cwd for example).

@sigmaSd
Copy link
Contributor

sigmaSd commented Jun 23, 2022

Here is a poc for this https://github.com/denoland/deno/compare/main...sigmaSd:tasksUp?expand=1

I wonder if its possible to support both the current and this requested schema and I wonder if that's a desirable thing to do.

@dsherret dsherret added suggestion suggestions for new features (yet to be agreed) task runner related to deno task labels Jun 24, 2022
@oscarotero
Copy link
Author

Someone had the same idea before: #14084

@kitsonk
Copy link
Contributor

kitsonk commented Jul 20, 2022

I'm in favour of this, I was going to actually raise an issue about this, as it improves the DX a lot more than #15241

ping @bartlomieju

@dsherret
Copy link
Member

A point brought up by @crowlKats is that this can be expressed with a comment in the configuration file. Also that tasks and names should be descriptive enough on their own, and if they're not then at that point a comment can be added.

I agree with that and don't think we should add this property unless we have another reason for introducing object notation.

@oscarotero
Copy link
Author

oscarotero commented Jul 20, 2022

Comments are available only in .jsonc format, so it's a broken solution to me, because it's not compatible with all file formats supported to configure Deno.
Also, AFAIK there's no support in std library to stringify data in JSONC, only parse, so there's no way to create or modify an existing jsonc file with deno.

FYI, Lume creates/modify the deno configuration file to add the import map and tasks and it doesn't support JSONC for this reason: lumeland/lume#211 (comment)

@nayeemrmn
Copy link
Collaborator

nayeemrmn commented Jul 20, 2022

Comments are available only in .jsonc format, so it's a broken solution to me, because it's not compatible with all file formats supported to configure Deno.

But jsonc exists for when you want to add comments, and that's why it's supported. The std lib can always be improved.

@oscarotero
Copy link
Author

oscarotero commented Jul 20, 2022

To me, a tasks description is a value that configure how this task should be displayed when the user run deno task. A comment in a jsonc can be anthing: a private comment like // todo: refactor this task, a previous comment that have been disabled, like:

{
    tasks: {
        //"format": "deno fmt .",
        "lint": "deno lint ."
    }
}

... etc. I wouldn't mix both things. The deno configuration (no matter the format used) should be based in real values. Treating comments like they were configuration values looks hacky to me.

@crowlKats
Copy link
Member

Closing as a PR was made but closed due to there being a consensus of not wanting to do this, and jsonc should be the way to achieve this.

@dsherret
Copy link
Member

Something similar to this proposal is now done in #23101 (displays the comments when running deno task)

@oscarotero
Copy link
Author

@dsherret I think using jsonc comments is a bad idea because it's mixing commented code that you don't want to use with task descriptions.

And, in addition to that, the jsonc parser of std removes the comments, so it's not possible to edit the file without removing these descriptions.

Object notation is a stronger way to have this.

@dsherret
Copy link
Member

I think using jsonc comments is a bad idea because it's mixing commented code that you don't want to use with task descriptions.

The output shows the comments as comments. I'm not sure why someone would comment above a task and not want that displayed when someone runs deno task.

And, in addition to that, the jsonc parser of std removes the comments, so it's not possible to edit the file without removing these descriptions.

The jsonc parser in std is severely lacking and should be improved to handle comments better. I don't think it should be a reason to drive the decision here. jsonc-parser on npm is much better for making modifications to jsonc files, for example.

@oscarotero
Copy link
Author

The output shows the comments as comments. I'm not sure why someone would comment above a task and not want that displayed when someone runs deno task.

Well, let's say I have 3 tasks, but I want to disable, temporarily one of them for some reason.

{
  "tasks": {
    "format": "deno fmt .",
    // "lint": "deno lint .",
    "test": "deno test ."
  }
}

Now the commented lint task becomes the description of test task.

@dsherret
Copy link
Member

Good point! I opened #23104 to improve it.

@oscarotero
Copy link
Author

oscarotero commented Mar 28, 2024

This is just an example, but what I want to say is the use of comments for task descriptions is a very weak approach because there are many edge cases that cause unexpected behaviors. It's not portable, because it doesn't work with json, only jsonc.
Allowing only block comments formats like this can help:

{
  "tasks": {
    "format": "deno fmt .",
    // "lint": "deno lint .",
    /** Task description */
    "test": "deno test ."
  }
}

But my opinion is it should be a json field. It's the most robust, portable and predictible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion suggestions for new features (yet to be agreed) task runner related to deno task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants