Support for Devcontainers?

[aj-stein]

Is your feature request related to a problem? Please describe it

I wanted to know if you considered supporting the .devcontainers specification for the tooling associated with this GitHub repo template.

Describe the solution you'd like

Run linting and analysis tools in a devcontainer in lieu of directly installing and executing Megalinter and its dependencies.

Describe alternatives you've considered

The current default of installed tools locally in the host where the repository is cloned, but I wanted to combine a collection of tools that defaults to devcontainers, and maintaing all the tools outside of one or more unified environments is annoying.

Additional context

[wesley-dean]

Branch 71-Support_for_Devcontainers created!

[wesley-dean]

I haven't really looked too deeply into this idea. I'm not yet very acquainted with devcontainers, so I haven't put a lot of effort into this. My understanding -- and correct me if I'm wrong -- is that devcontainers specify a mechanism for a development environment to be containerized along with whatever tooling the development environment requires (compilers, linters, etc.). So, a devcontainers for a Python project would have Python, pylint, black, ruff, etc.. Since the template repo could be used by any project regardless of the language, I don't know how to proceed with this.

One option I'm thinking about could be sample devcontainer specifications for Python projects, Go projects, etc. and allow the repo users to pull in the specification that they want to use.

Another option would be to include some kind of metatooling that would allow the repo users to generate a devcontainer specification that would match the repo. I don't know if there exist tools out there that can help with this.

[wesley-dean]

I asked ChatGPT what it thinks and it provided the following:

This is a good question, and I finally took some time to read through the devcontainer spec a bit more closely to make sure I wasn’t hand-waving.

Your mental model is basically right. Devcontainers are about standardizing how a development environment is described and spun up in a container: what base image or Dockerfile to use, what tooling gets installed, and how the editor hooks into it. The spec is very intentionally neutral about languages and tools, and mostly focuses on making that experience portable across editors and platforms.

Where I keep getting stuck is that tension between language-agnostic template and language-specific dev environments. This repo is meant to be usable for pretty much anything, while devcontainers really shine when they’re tailored to a specific stack (Python + Ruff/Black, Go + golangci-lint, etc.). A single default devcontainer here would either be too empty to be useful or too opinionated for a general template.

A couple ideas that feel more realistic to me:

• Having example devcontainers for common stacks (Python, Go, maybe Node), clearly documented as optional references rather than something the template assumes.
• Adding guidance on how people can pair this template with devcontainers if they want to run MegaLinter or other tooling inside a container instead of installing things locally.
• Keeping devcontainers firmly in the “developer experience” lane, while CI and enforcement stay decoupled and runner-agnostic.

I’m a lot less convinced about generating devcontainers automatically. From what I can tell, the spec very deliberately avoids standardizing detection or synthesis of toolchains, and anything we built there would probably end up being heuristic-heavy and brittle.

All that said, I think your instinct is solid. I just want to be careful about not baking something language- or workflow-specific into a repo that’s trying hard to stay flexible. If you have a concrete stack in mind that you think would be a good first example, I’m happy to think it through with you.