In the current model, all types of commands are expected to have an id that is mainly the key of the command in the command list.

It is defined this way:

commands:
  - exec:
      id: "commandId"  <------ the key of the given command in the list of commands 

Since finally the id field is common to all types of command and is the key that will be used to identify a command, especially when merging commands between a parent and the current devfile, it seems it might make sense to bring it one level up, like this:

commands:
  - id: "commandId"
    exec:
      ....

The same stands for components: until now all types of components have a name field that is used as a key for identifying a component, especially during parent or plugin overriding. It is mandatory for most component types, and optional for plugins, in which case it is calculated from the definition of the plugin itself (based on id, registry url, etc ...).

Instead of:

components:
  - container:
      name: "tooling"

we would have

components:
  - name: "tooling"
    container:
      ....

In this case, though, the name field can only be made either required or optional for all the component types, and not per-component-type. We should then probably make it mandatory for the Kubernetes CR, and optional for devfiles (but for all components). This would lead to loosing some schema validation.

Of course, deciding that in any case we require a name for a component (even a plugin) would make the whole more consistent and schema-validated, but less user-friendly I admit.

So this proposal surely requires further discussion. But it could be interesting to decide upon this before the Devfile 2.0.0 release.

Related content: #98 (comment)