Add option to opt out of extensions

Some features install extensions along with themselves and I'm not always interested in them. For example, the golang.Go extension that is installed in the Go feature or the dbaeumer.vscode-eslint extension that is installed in the Node feature are not extensions that I use.

To prevent bloat it would be very nice if extensions could be opted out of in feature options.

Here is an example of how I think this could work:

"features": {
  "ghcr.io/devcontainers/features/node:1": {
     "extensions": {
        "dbaeumer.vscode-eslint": false
     }
  }
}

[samruddhikhandale]

Hi @andreilg 👋

devcontainers/cli#262 introduced an experimental --skip-persisting-customizations-from-features flag for the devcontainer build command. It omits all the Feature specified customizations ie. if your devcontainer.json referred to a set of Features, then their corresponding customizations (which includes extensions) will not be applied to your dev container.

Wondering if that could be sufficient for your scenario? I could help make this flag more formalized.

Let me know if your scenario requires more control/options to pick & choose the customizations/extensions, then we could chat further.

Thank you for your response.

The way I'm currently using devcontainers is through a devcontainer.json file with features running in GitHub Codespaces.

That cli flag seems helpful but I don't necessarily want to turn off all customizations or even all extensions but rather pick and choose within the devcontainer.json feature what customizations to include.

My suggested example above is how I envision this could work since it allows for granular control of customizations.

[samruddhikhandale]

Thanks for the clarification.

Here is an example of how I think this could work:

"features": {
    "ghcr.io/devcontainers/features/node:1":
        "extensions": [
            "dbaeumer.vscode-eslint": false
        ]
}

Shouldn't extensions be wrapped in an object? 👇

"features": {
    "ghcr.io/devcontainers/features/node:1": {
          "extensions": [
              "dbaeumer.vscode-eslint": false
          ]
     }
}

Currently, every key-value inside this object is expected to be a Feature option. Doing something like this needs a spec change & would need to reserve 'extensions' keyword for this specific purpose. This could potentially be a breaking change for authors who have been using extensions as a Feature option in their devcontainer-feature.json.

Instead, I am thinking of a similar but a little tweaked approach to your suggestion.

"features": {
    "ghcr.io/devcontainers/features/node:1": {
        "_DISABLE_VSCODE_EXTENSIONS": [
            "dbaeumer.vscode-eslint" // or use "*" to disable all extensions
        ]
    }
},

The Features' option expects camel case, hence, shouldn't break any existing dev configs. We could make a spec change to support this.

@Chuxel / @bamurtaugh Would appreciate your thoughts on this one 👀

[bamurtaugh]

Thanks for the tag, @samruddhikhandale! And thanks for opening, @andreilg - this is an interesting scenario.

@samruddhikhandale I like your idea above that avoids potentially breaking users. I'd be interested to see if other folks mention this as a helpful or important addition for them. I'm going to pop this issue in our dev container community Slack channel to get some more 👀

Shouldn't extensions be wrapped in an object? 👇

Yes, my mistake. The array should also be an object I believe. I have updated my original post.

This could potentially be a breaking change for users who have been using extensions as a Feature option in their devcontainer-feature.json.

I see what you mean since the azure-cli feature has an extensions feature option already.

Instead, I am thinking of a similar but a little tweaked approach to your suggestion.

That looks like a good way of going about it.

Edit:
@bamurtaugh Thank you. To give a little more context for why I personally want this:

• I don't need the Go extension since I'm only using Go to get Hugo Modules in Hugo to work.
• I don't need the ESLint extension because I use Trunk for linting.

With the nature of codespaces, I feel like any possibility to reduce bloat will always be desirable and I imagine a lot of people are in a similar situation and just find the lack of control over customization to be a minor annoyance that can add up over time.

[chrmarti]

In the devcontainer.json we use "customizations" to add extensions, that would also be a good place to remove them, e.g.:

	"customizations": {
		"vscode": {
			"extensions": {
				"dbaeumer.vscode-eslint": false,
				"ms-python.python": true
			}
		}
	},

(The current "extensions" property uses an array to add extensions.)

[samruddhikhandale]

A similar request was reported in devcontainers/action#139.

[Chuxel]

If we limit this to just extensions, the proposal in microsoft/vscode-remote-release#415 isn't a bad one. Just prefix the name with a "-" to omit.

	"customizations": {
		"vscode": {
			"extensions": {
				"-dbaeumer.vscode-eslint",
				"ms-python.python"
			}
		}
	}