Many people who work with me know that I hate anything related to frontend :).
I only work with backend, but sometimes I still have situations when I need to run some GUI which brings pain: you need to have version x for node, version y for npm for one project, then another project requires different versions and other dependencies… And you need to follow all the different scripts for how to start all that mess in each project. Meeeh…
As I said - I don’t want to have any business with frontend at all - so to minimize the attention I need to put on frontend I decided to automate the set up of a frontend development environment by using containers. This way I can focus on the fun stuff and getting past the necessary much quicker. Enjoy!
In this guide I use:
- Visual Studio Code
- Remote - Containers plugin for VSCode
- In the root directory of your project, you need to create a folder called
.devcontainer. Here you will store the settings for your environment.
devcontainer.jsonfile must be created in this folder as Visual Studio Code expects this file structure.
Dockerfilecan be either created in this folder or in the root of your project. I usually put it in the root.
.dockerignorefile is needed if you would like to ignore some files/folders for docker
run.shshell script with automation commands
Let’s take a look at
devcontainer.json and describe what we are doing here:
name- is pretty obvious :)
dockerFile- relative path to a Dockerfile that you wish to use as your image
extensions- an array of extension ids that will be installed inside the container
settings- default values inside the container
mounts- maps source folder from your file system to targer container file system
These are the options that I used in my projects, but there are more that might be useful:
appPort- a port or an array of ports that should be available locally when container is running
postCreateCommand- a list of command arguments to run after the container is created
runArgs- an array of Docker CLI arguments that should be used when running the container
FROM- you choose which image you work with in your project
WORKDIR- working directory within container
COPY- for this demo I copy everything but you can create multi-stage dockerfile and build step-by-step
VOLUME- creates a mount point and marks it as holding externally mounted volumes from native host or other containers
You can ignore the
node_modules folder if you want to skip copying half of the universe when you build your container.
Since I did not want to type all the commands manually I created a script file which will be executed each time when a new terminal window is opened. And for cases when you actually need to work with a terminal the script provides you an option to just start bash.
So you may already have noticed that there is a new green icon in the left bottom corner of your Visual Studio Code.
If you click on the button it will provide several options on how to use your remote container.
Reopen in Container to build it and start the container. This will reopen the visual studio code and start building the image (if you have already done this before it will also prompt to rebuild the image if you have made some changes in the configuration), after a successful build a new terminal window shall be opened with a nice prompt for you.
Now you can use your magic for frontend.
devcontainer.jsonI mounted wwwroot folder just because in my project it copies all frontend output to this folder within my ASP.Net Core project so when I start the web api I can navigate directly to GUI without starting a node instance on another port. This you can do as well by just specifing the
appPortand editing the automation script.
This is the perfect example of how lazyness can trigger people to find bypass solutions, especially for frontend…