VM development progresses! Move node_modules wherever you like and use them!

Hello.
I'm Mandai, in charge of Wild on the development team.

Even if you don't develop a system with Node.js, I think there is a common pattern of using Node.js to reduce the workload.
For example, I use webpack to precompile CSS and transpile JS files, and for routine tasks I use gulp to create scripts and run them regularly.There are various use cases, and it is steadily becoming a part of my daily life. I feel like that.

There is a package management tool for Node.js called npm, but this time we have summarized what to do when you need to move the node_modules directory outside the project directory for some reason.

 

What is a certain reason? !

The reason is a problem with the development environment.

I think a VM is often used as a development environment, but this time I will use Windows 10 as the host OS, running CentOS 7 on Virtualbox (and managing it with vagrant). It's a certain form.
There was an unexpected pitfall in such a common development environment.

It may seem sudden, but one of my particular points is that I always use Visual Studio Code (hereinafter referred to as VSCode) when developing, and this year I'm thinking of sticking to it, and it's already August this year, and I've gotten used to it quite a bit. .
VSCode is developed with Node.js (TypeScript) and uses Electron to become an editor that can be used on multiple platforms.

It is!

VSCode shortcut keys are difficult to use on Linux, so there is no option to install VSCode on a VM and develop with it. That's nothing but stress (I'm sure the Windows version is incredibly easy to use because it was developed by Microsoft).

Therefore, the configuration of the development environment also needs to be changed around VSCode.

In conclusion, by sharing the entire project directory using VirtualBox's shared folder function, the content edited with Windows VSCode is shared with the VM, and that's it.
If you start the VM in headless mode, you can reduce the unexpected load, so you can run up to 3 VMs.

 

Pitfall #1 “The node_modules directory cannot be shared”

Assuming you understand the situation, the big question remains.
That's the problem: "The node_modules directory cannot be shared."

The files can be shared, but if you think about it carefully, node_modules are created based on the platform at the time of npm install, so problems may occur with modules that include platform-dependent binaries.

This problem seems to be resolved if you put node_modules outside the project directory.
Instead, you will need to do npm install for each development platform, but I think that's what npm install is, so I don't really worry about it.

 

Pitfall #2 “Maximum call stack size exceeded”

When doing npm install inside a shared folder, I often come across the error "Maximum call stack size exceeded".
I didn't really understand it, but it seems that the cause of this error is the shared folder. References - npm ERR! code ETXTBSY · Issue #9979 · npm/npm · GitHub

So, this problem seems to be solved by placing node_modules outside the project directory.

 

Install node_modules wherever you like

Actually, you can change the location of node_modules using the npm config command.
It can be changed with the following command.

npm config set prefix "/home/vagrant"

 

The node_modules directory recognized by npm is now "/home/vagrant/node_modules".

However, this only means that npm now recognizes the location of node_modules as "/home/vagrant/node_modules", so even if you run npm install in this state, node_modules will still be located at the same level as package.json. It's persistent...

Therefore, specify the prefix in the installation command as well, and install with the following command.

npm install --prefix "/home/vagrant"

 

This will probably cause an error.
This kind of error.

npm WARN saveError ENOENT: no such file or directory, open '/home/vagrant/package.json'

 

There is no package.json! There is!
When I thought about it, package.json was needed in the directory specified by --prefix!

Hard copying would be difficult to manage, so we will use symbolic links.

cd /home/vagrant ln -s /home/vagrant/src/package.json ln -s /home/vagrant/src/package-lock.json # Sometimes

 

It's a matter of having package-lock.json, but in the case of a first-time installation, the original will exist in "/home/vagrant", so once the installation is finished, you have to copy it to the working directory. occurs.
This is also for VSCode. I can't help it.

After that, run npm install with the prefix to proceed with the installation.

As a side note, I thought that npm install was extremely slow, but when I ran it outside of the shared folder, it ended up being a mess.
Shared folders are convenient, but slow.

 

Sometimes it's not just about being anywhere.

Even though I said it can be installed anywhere, that doesn't mean it can be installed anywhere.
The following is what happens when node_modules is installed in a certain directory and the task runner gulp is executed.

gulp sass [06:46:05] Local gulp not found in ~/src [06:46:05] Try running: npm install gulp

 

I'm sure that gulp is installed both globally and locally, so I think the reason for the strangeness is that node_modules is not in the same layer as package.json.
I couldn't seem to figure it out after a bit of Googling, so I looked at the gulp source and found out. → gulp-cli/index.js at master · gulpjs/gulp-cli · GitHub

Since the only strings contained in the cfgLoadOrder array are home and cwd, it seems best to bring node_modules directly under the home directory.
That's why the prefix of the command pasted in the sample is the home directory.

When I created node_modules under my home directory, I was able to successfully execute gulp tasks even if node_modules was not in the usual location.

I feel like writing a config file would give me more freedom, but I didn't really understand this, so I'll look into it if I have time.

 

summary

I've gone off track in various ways, and the text has become a bit of a mess, so I'll summarize it here.

• There are cases where the npm install directory cannot be shared in the VM's shared folder.
  • NG if you use a module that requires platform-dependent binaries
  • Due to the nature of shared folders, you cannot even run npm install on the shared folder.
  • If the host and guest are *nix systems, maybe it's OK?
• The location where node_modules are created can be changed using the option "--prefix" of the npm install command.
• Package.json must be placed in the directory specified by "--prefix" in advance (symbolic link is also OK)
• Sometimes, such as gulp, the position of node_modules is not free.
• node.js is convenient

In the end, I think it would be better to just put it directly under the home directory.
I use a different VM for each project, and even though I could manage it with a config file, I thought it would be strange to use gitignore just for myself.

It was great to be able to separate node_modules from the working directory.

 
That's it.