Devcontainers are a feature of VS Code which may allow for a more consistent development experience across all devices.
Related to #220 ?
Under-the-Hood Changes
The hearts of Devcontainers is a .devcontainers/ folder which triggers functionality in VS Code. If you are not using VS Code, or choose not to use Devcontainers, there is no change to your experience from the current setup. VS Code simply automates the setup, and creates a consistent environment.
Pre-requisite
Devcontainers requires VS Code, Docker, and the Remote - Containers extension. With the extension installed, a developer opening HuntersKeepers in VS Code will be presented with a dialog box:
Upon clicking "Reopen in Container", VS Code will begin a process to bring up a copy of HuntersKeepers, while running all required setup steps (see .devcontainers/startup.sh for commands). This may take a while as all Docker images are built, gem/node modules installed, and the database is created / seeded. Clicking "(show log)", in the VS Code pop-over will show the log of what is being done.
Once the initial build is completed, a container will be visible from the host machine in which VS Code will be executing. If you open a terminal inside VS Code, you will see a prompt from within the container.
By default, the walkme.ruby-extension-pack pack will be installed within the container. In addition, Solargraph and Rubocop are installed within the container and should be available to VS Code's extensions.
Implementation
There are many ways to implement Devcontainers. I've included the two methods which I feel offer common features. If there are alternative implementations, please feel free to add them!
Native-Like experience
One implementation of Devcontainers acts very similar to a native-development experience. To run rspec, one simply runs rspec in the VS Code terminal, the same goes for bundle, yarn, and other commands. Guides for working in Rails should apply as if Docker was not involved and all commands should work the same on any machine.
Another implementation allows users to run docker-compose commands from within the running container. This has the advantage that there is only a single set of documentation which should apply to both Devcontainers users and non-Devcontainers users.
This implementation does have the downside of spinning up one extra container.
I think that Devcontainers offers one of the best experiences for a consistent development environment regardless of host machine, as well as automating common setup tasks.
Describe the Feature
Devcontainers are a feature of VS Code which may allow for a more consistent development experience across all devices.
Related to #220 ?
Under-the-Hood Changes
The hearts of Devcontainers is a
.devcontainers/
folder which triggers functionality in VS Code. If you are not using VS Code, or choose not to use Devcontainers, there is no change to your experience from the current setup. VS Code simply automates the setup, and creates a consistent environment.Pre-requisite
Devcontainers requires VS Code, Docker, and the Remote - Containers extension. With the extension installed, a developer opening HuntersKeepers in VS Code will be presented with a dialog box:
Upon clicking "Reopen in Container", VS Code will begin a process to bring up a copy of HuntersKeepers, while running all required setup steps (see
.devcontainers/startup.sh
for commands). This may take a while as all Docker images are built, gem/node modules installed, and the database is created / seeded. Clicking "(show log)", in the VS Code pop-over will show the log of what is being done.Once the initial build is completed, a container will be visible from the host machine in which VS Code will be executing. If you open a terminal inside VS Code, you will see a prompt from within the container.
By default, the walkme.ruby-extension-pack pack will be installed within the container. In addition, Solargraph and Rubocop are installed within the container and should be available to VS Code's extensions.
Implementation
There are many ways to implement Devcontainers. I've included the two methods which I feel offer common features. If there are alternative implementations, please feel free to add them!
Native-Like experience
One implementation of Devcontainers acts very similar to a native-development experience. To run
rspec
, one simply runsrspec
in the VS Code terminal, the same goes forbundle
,yarn
, and other commands. Guides for working in Rails should apply as if Docker was not involved and all commands should work the same on any machine.Native-like reference implementation.
Docker-Compose experience
Another implementation allows users to run
docker-compose
commands from within the running container. This has the advantage that there is only a single set of documentation which should apply to both Devcontainers users and non-Devcontainers users.This implementation does have the downside of spinning up one extra container.
Docker-Compose reference implementation.
Conclusion
I think that Devcontainers offers one of the best experiences for a consistent development environment regardless of host machine, as well as automating common setup tasks.