Is it possible to move features inside the Dockerfile, with FROM clauses for example?

[mattaereal]

There are a lot of dev-container features that solve many things, but since the Dockerfile runs first I need some of what those features install later earlier under the Dockerfile context.

Can I somehow get them to work with FROM clauses?

[mattaereal]

More than one FROM clause can be used in a multi-stage build. So it should be possible to reference different builds that will end up being merged upon building. The following question will be, can features be used like that? Most of them have a Dockerfile, so it could be.

[pegahcarter]

Exactly what features are we looking to add? Is it worth breaking them down by order of urgency / will they require a specific install order?

[mattaereal]

The thing is that I'd rather use features to avoid doing a bunch of manual installations like I would rather delegate the responsibility to maintain the proper way to install node, pnpm for example. There's a feature that installs them both using nvm, which also solves the need to install nvm, which is awesome.

The thing is that since there's no devcontainer feature to install apps like Hardhat, you only have two options:

1. You install hardhat using a devcontainer post-installation script (calling postCreateCommand), which you must download from somewhere else to avoid mounting your fs. Could also just run pnpm -i hardhat on that command inside the devcontainer (for a proper example see the article branch), but that would mean having a LOT of stuff being installed right after the creation, and will make it unmaintainable.

2. You install hardhat and other tools in the Dockerfile. This would mean to forgo the pnpm/nvm/node feature since in this case I would NEED them to be installed before trying to install hardhat.

That's why I currently opted for the second option, since it is more performant, pollutes less the devcontainer.json, and allows me to do whatever I want*.

• almost, installing things that require env paths is a nightmare, everything has to happen within the same context and that's why you'll see fully concatenated commands in order not to lose that context.

[pegahcarter]

What if we stored the config in a base home directory (and use some dreaded env paths) to prevent dup installs?

To extend this, you could hop into a "hardhat" or "foundry" alias within a repo to reference only the required packages in the base dir. Other aliases could be developed to support specific package managers, node versions etc. based on the project build.

[mattaereal]

I'll have to think more about this. Since hardhat has been advising not to install it globally, but rather locally on each project to avoid compatibility issues