Thanks for the feedback!

Yet, in the documentation link I see no such rules too, so quite confused: should we actually do what's proposed in the issue, what's in the PR, something else?

The issue mentions grunt and typescript task types, but these aren't currently supported by Zed's parser. Adding label generation for them would require first implementing full parsing support. Here's what Zed currently handles:

enum Command {
    Npm {
        script: String,
    },
    Shell {
        command: String,
        #[serde(default)]
        args: Vec<String>,
    },
    Gulp {
        task: String,
    },
}

Can we have a link to the docs/sources with these rules?

Sure! Here's where VSCode implements this:

The core logic is in taskConfiguration.ts lines 1533-1547:
https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/tasks/common/taskConfiguration.ts#L1533-L1547

if (result.configurationProperties.name) {
    result._label = result.configurationProperties.name;
} else {
    let label = result.configures.type;
    if (typeDeclaration.required && typeDeclaration.required.length > 0) {
        for (const required of typeDeclaration.required) {
            const value = result.configures[required];
            if (value) {
                label = label + ': ' + value;
                break;
            }
        }
    }
    result._label = label;
}

Basically: if there's no label field, VSCode takes the task type and appends the first required property value.

The task type definitions show what's required:

https://github.com/microsoft/vscode/blob/main/extensions/npm/package.json#L344-L360
https://github.com/microsoft/vscode/blob/main/extensions/gulp/package.json#L49-L69
https://github.com/microsoft/vscode/blob/main/extensions/grunt/package.json#L50-L71
https://github.com/microsoft/vscode/blob/main/extensions/typescript-language-features/package.json#L1894-L1910
https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/tasks/common/taskConfiguration.ts#L1574-L1576

if (!taskName) {
    context.problemReporter.error(nls.localize('ConfigurationParser.noTaskName',
        'Error: a task must provide a label property. The task will be ignored.\n{0}\n',
        JSON.stringify(external, null, 4)));
    return undefined;
}

This brings up the shell task question - the PR currently generates labels for shell tasks (using the first word of the command), but VSCode actually errors on these.

We have a few options:

1. Match VSCode and reject shell tasks without labels
2. Keep the current behavior (more permissive)
3. Accept them but log a warning

I'd lean toward option 2 since it's more user-friendly and Zed already diverges from VSCode on which task types are supported. But what's your preference?

Lastly, we want to test more conversion cases for coverage, even at the current PR's state.

Done! I refactored the label generation into a standalone generate_label() function that can be tested independently.

is it really ok to keep just the first word of the command? I imagine there could be multiple echo or cargo or npm or whatnot and we'll have a conflict — instead, does it make sense to have the entire command as a label?

Good catch, improved it the way you suggested. Did a quick check what zed does with very long labels. No issue as far as I can see.
Just kept the fallback to "shell" for blank strings.