VM development will progress! Move node_modules to wherever you like and use it!

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

Even if you don't develop a system with Node.js, it's common to use it to reduce your workload.
For example, you might use webpack to precompile CSS or transpile JS files, or use gulp to create scripts for routine tasks and run them periodically. There are many use cases, and I feel like it's steadily becoming a part of our lives.

There is a package management tool for Node.js called npm, and 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 that certain reason?!

The reason is due to the development environment

VMs are commonly used as development environments, and in this case, the setup is a typical one: Windows 10 as the host OS, running CentOS 7 in VirtualBox (and managed by Vagrant).
However, this common development environment had an unexpected pitfall.

This might seem sudden, but one of my personal preferences this year is to always use Visual Studio Code (VS Code) when developing, and it's already August, so I've become quite familiar with it.
VS Code is developed using Node.js (TypeScript) and is a multi-platform editor that uses Electron.

It has become so!

The shortcut keys for VSCode are quite difficult to use on the Linux version, so installing VSCode on a VM and developing with it is not an option, which is just frustrating (the Windows version's incredible ease of use is probably due to the fact that it was developed by Microsoft)

Therefore, the configuration of the development environment also needs to be tweaked with VSCode as the core

In short, I'm simply sharing the entire project directory using VirtualBox's shared folder feature, allowing me to share the content edited in VS Code on Windows with the VM.
If you start the VM in headless mode, the load is surprisingly low, so you can run up to three VMs.

 

Pitfall #1: The node_modules directory cannot be shared

Assuming you understand the situation, a major problem remains:
the node_modules directory cannot be shared.

Although the files can be shared, if you think about it carefully, node_modules is created for the platform at the time of npm install, which can cause problems with modules that contain platform-dependent binaries

If we can place node_modules outside the project directory, this problem should be solved.
However, this would require running `npm install` for each development platform, but I'm not too concerned about that since that's just how `npm install` works.

 

Pitfall #2: "Maximum call stack size exceeded"

When running `npm install` in a shared folder, I often encounter the error "Maximum call stack size exceeded."
I didn't fully understand it at first, but it seems the cause of this error is related to the shared folder. References: npm ERR! code ETXTBSY · Issue #9979 · npm/npm · GitHub

So, this problem can 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.
You can change it with the following command:

npm config set prefix "/home/vagrant"

 

Now the node_modules directory recognized by npm is "/home/vagrant/node_modules"

However, this only makes npm recognize 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 at the same level as package.json. That's annoying..

Therefore, you will need to specify the prefix in the installation command and install it using the following command

npm install --prefix "/home/vagrant"

 

Doing this will probably result in an error.
An error like this.

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

 

I had a package.json file
but it turns out you need a package.json in the directory specified by --prefix!

Hard copies are 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 # sometime

 

This assumes that a package-lock.json file exists, but for the first installation, the original will actually be located in "/home/vagrant," so after installation, you'll have to perform the strange task of copying it to your working directory.
This is also due to VS Code. It can't be helped.

Then just run npm install with the prefix to proceed with the installation

As a side note, I thought `npm install` was incredibly slow, but when I ran it outside of the shared folder, it finished in a flash.
Shared folders are convenient, but they're slow, aren't they?

 

Sometimes it's not okay to go anywhere

Despite saying it can be installed anywhere, it's not really possible to install it just anywhere.
The following describes what happens when you install node_modules in a certain directory and then run the task runner gulp.

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

 

I'm certain I have gulp installed both globally and locally, so I think the problem is that node_modules isn't at the same level as package.json.
A quick Google search didn't seem to help, so I took a look at the gulp source code and kind of figured it out. → gulp-cli/index.js at master · gulpjs/gulp-cli · GitHub

The only strings in the cfgLoadOrder array are "home" and "cwd," so it seems like you should just put node_modules directly under your home directory.
That's why the command prefix in the sample I pasted is your home directory.

If you create node_modules under your home directory, you can run gulp tasks successfully even if node_modules is not in the usual location

I have a feeling that writing a configuration file would give me more freedom, but I'm not sure about that, so I'll look into it when I have time

 

summary

I've gone off on a tangent a lot and the article has become quite disorganized, so I'll summarize it here

• In some cases, the directory where npm install is installed cannot be shared in the VM's shared folder
  • If you are using a module that requires platform-dependent binaries, it will not work
  • Due to the nature of shared folders, even npm install cannot be done on shared folders
  • If the host and guest are *nix based, maybe it's OK?
• The location where node_modules is created can be changed with the npm install command option "--prefix"
• The directory specified with "--prefix" must already contain package.json (a symbolic link is also OK)
• Sometimes, such as with gulp, the location of node_modules cannot be freely determined
• Node.js is useful

I think putting it directly under my home directory is probably best.
I use a different VM for each project, and even if I could manage it with a configuration file, it feels wrong to create a .gitignore just for myself.

I was glad that node_modules was separated from the working directory

 
That's all