Composable package.json extension manifest contributions through the use of external files

[rbuckton]

For any large extension the size of the "contributes" entry in package.json can also grow to be extremely large and difficult to maintain, especially since you cannot organize contributions by feature or add comments (since package.json must be pure JSON).

I would propose adding something like the following to "contributes" to allow for composition of extension contributions from one or more external files:

{
   "contributes": {
      "include": [
        "feature1.json",
        "feature2.json",
        ...
      ],
      ...
    }
}

Where "feature1.json" might be:

// contributions for feature1
{
  "commands": [
    ...
  ],
  "menus": [
    ...
  ],
  // other contribution points
}

The proposed order of composition would be:

1. Contributions provided by each file in "include" are applied in array order.
2. Contributions from package.json are applied last.

In the event of a collision where two contribution sources define the same contribution (such as two commands with the same name), I see at least two options:

1. Error when activating an extension with collisions, or
2. The last in wins, but vsce could provide errors or warnings for collisions prior to packing/publishing.

I'm generally in favor of "last in wins" so as not to hamper local development/testing while refactoring an extension, but don't have a strong preference either way.

One caveat to this approach is that there would need to be some way for VS Code to know that feature1.json is an external contribution manifest. This could possibly be accomplished by using a well-defined filename format such as <name>-contributions.json (similar to language-configuration.json), or by using a "$schema" entry on the top-level object.

[alexdima]

I agree with the pain-point. IMHO the pain is even greater than having a lot of objects in the contributes section. Other very annoying aspects of authoring package.json:

• nls strings must be manually extracted to package.nls.json and % strings must be manually created with identifiers, making it very difficult to remember which id was which command (what the title was, etc.)
• needing to write the command ids twice most of the time, once when they are contributed, and again as activation events
• having a "nightly" variant of the extension which needs to copy-paste the entire package.json and then changes only the name.