- Phpstorm docker node debug install#
- Phpstorm docker node debug code#
Phpstorm docker node debug code#
We really had to use that less-than-optimal hack to modify the package.PhpStorm is a lightweight and smart PHP IDE focused on developer productivity that deeply understands your code, provides smart code completion, quick navigation and on-the-fly error checking. the “ docker run -w / -workdir” parameter did not help. JetBrains doesn’t tell us anything about it. any /opt/project/node_modules will be overwritten by force.Īs we cared about that by using the /opt parent folder for the node_modules installation, and we set the WORKDIR to be /opt/project one could think that now we can just call the development server (written as above).įor reasons that made us question our reality way longer than it made us happy, it turned out that the IDE somehow always chose the /tmp/ path as WORKDIR.
Phpstorm docker node debug install#
This mounting behaviour explains why we cannot install our node_modules dependencies inside the container in the /opt/project path – mounting external folders always override anything that might exist in the corresponding mount points, e.g. If you run this configuration, your current project directory is going to be mounted in two places inside the container: Now enters that strange IDE behaviour that is not really documented or changeable anywhere.
“+” ➔ “npm” ➔ Node interpreter “Add…” ➔ “Add Remote” ➔ “Docker” Now, the current JetBrains IDEs allow you to run your project with the node interpreter (containerized within the node-platform image) in the “Run/Debug Configurations” window via This will work because for lack of an own node_modules, node will find it above (this fact might change with future Node versions, but for now it holds true). Because this blog post is going somewhere, already now we chose to place that node_modules in the parent folder of the actual WORKDIR. Now, if we are not working against any idiosyncrasies of an IDE, the preparation step “npm ci” gives us all our node dependencies in the current directory inside a node_modules/ folder. If you are not interested in that, that path is for you to choose.
We specifically have to take the WORKDIR /opt/project because our mission statement is to integrate the whole thing with WebStorm. One could improve that by adding another step beforehand, only preparing a vite+node base image and taking advantage of Docker caching from then on. The RUN step to npm install -g vite is required for a Vite project because the our chosen base image node:18-bullseye does not know about the vite binaries. are chilling) docker build -t build-platform-image -target build-platform. The “build platform” stage can then be used as our Dev Container, from the command line as (assuming, this Dockerfile resides inside your project directory where also src/ etc. # -ĬMD npm run build & mv dist /build/result/app (Further reading: Docker cache management)įor one of our current React projects (in which I chose to try Vite in favor of the outdated Create-React-App, see also here), the Dockerfile might look like for running the build in production, or for further dependencies), but the basic distinction above helps us to speed up the development process already. one to execute the build itself (only this stage copies actual sources). one to prepare the build platform (this will be used for the DevContainer). In our projects, we usually have at least two Docker build stages: for WebStorm, there is some kind of support for dockerized run configurations, but that does some weird stuff (see below), and JetBrains did not care enough yet to make that configurable, or at least to communicate the sense behind that. This is the main advantage of the development container (DevContainer) approach (with Docker being the major contestant at the moment), and last November, I tried to outline my then-current understanding of integrating such an approach with the JetBrains IDEs. Who isn’t?Īt Softwareschneiderei, we have about five times as many projects than we have developers (without being overworked, by the way) and each of that comes with its own requirements, so it is important to be able to switch between different projects as easily as cloning a git repository, avoiding meticulous configuration of your development machines that might break on any change. We are always in pursue of improving our build and development infrastructures.
0 kommentar(er)
