Define what is "worthy"

[jcbhmr]

I think anything should not be added at this point as there are no acceptance criteria for this repository.

For example, there are clear criteria in linguist that control the language that GitHub recognizes. > We need to determine such criteria.
https://github.com/github-linguist/linguist/blob/master/CONTRIBUTING.md#adding-an-extension-to-a-language

Originally posted by @eitsupi in #16 (comment)

[eitsupi]

Some repositories are working with a mechanism to add feature requests that have received more than a certain number of +1 votes within a certain period of time to the backlog.
Such a thing could be used as a criterion, but obviously it will only work in situations where the repository has a large number of subscribers.

[jcbhmr]

There seems to be a lot of feature-like things going on in the original vscode-dev-containers script-library folder: https://github.com/microsoft/vscode-dev-containers/tree/main/script-library

I assume this was the precursor to devcontainer features? particularly given that there's what appears to be a prototype of the feature json schema/example in https://github.com/microsoft/vscode-dev-containers/tree/main/script-library/container-features#readme

here's a rough list of what was in https://github.com/microsoft/vscode-dev-containers/tree/main/script-library

• Java
• Kubectl & Helm
• Rust
• Terraform
• AWS cli
• Azure cli
• Docker
• Dotnet
• Fish shell
• Git
• GitHub cli
• Go
• Gradle
• Homebrew
• JupyterLab
• Maven
• Node.js
• Powershell
• Python
• Ruby

most (I think all of them?) are in https://github.com/devcontainers/features/tree/main/src

[eitsupi]

They are the predecessors of Dev Container Features.
They are currently hard coded here in the CLI.
https://github.com/devcontainers/cli/blob/3b8e16506456b4d50d05a6056eb65cf8a28ee834/src/spec-configuration/containerFeaturesConfiguration.ts#L749-L785

Currently they have all been replaced by Dev Container Features or incorporated into other Features.

[eitsupi]

By the way, only Homebrew and Fish were managed by the community among them, and I was the one who added Fish.

[jcbhmr]

unrelated, but inspired by https://github.com/orgs/devcontainers-community/discussions/7

imo: why making everything a devcontainer feature isn't always a good idea: (why this issue #17 needs to exist)

for instance, take browserify: you install it like npm install -D browserify and it gets added to your package.json, not your global env. if this were made a feature (like it already has been) that's not the greatest since it enables and possibly even encourages the bad habit of specifying deps as globals instead of in package.json. even if they are specified in devcontainer.json, that's a completely different toolchain that some rando on a Raspberry Pi needs to figure out in order to just clone and get the project going.

imo global deps are avoided if possible but inevitable a lot of the time. like npm and node are global deps 🤷‍♀️ same with python3, cargo, bash, etc.

point being, not every npm package should be a feature which is why #17 should exist (thanks @eitsupi for pushing for this!)

as a solution for this, i usually recommend using postCreateCommand or a package.json/requirements.txt-like file instead for "lesser" or from-a-package-manager dependencies like that (except apt packages; apt isn't great for getting latest package versions 😢). in fact, there's "official precedant" for this in the form of postCreateCommand: "npm install -g @devcontainers/cli" from https://github.com/devcontainers/features/blob/main/.devcontainer.json#L14 !😊