3

Some node modules have specific platform install requirements. For example, node-sass cannot be built on a mac and used on windows or linux. It can run on windows, but only if you build it on windows. Because of its node-gyp dependency, it must be specifically built on the platform for which you intend to run it.

Whereas lodash has no such complexity.

Is there any (ideally, automatic or programmatic) way to know which packages work like node-sass, and which work like lodash, apart from reading the documentation for each package/manually experimenting?

I want to mount my node_modules directory to a docker container, but I want to install my node modules locally on the host. That doesn't work for any modules such as node-sass.

Mureinik
  • 297,002
  • 52
  • 306
  • 350
Joe Fraley
  • 33
  • 3

2 Answers2

1

The package.json file should specify any OS limitations the package has using the os property, e.g. "os" : [ "darwin", "linux" ] or even "os" : [ "!win32" ].

Having said that, there's no real way of enforcing the use of this property, and a package author can just omit (or forget!) to specify the os property in the package.json file but still write a package that will only work on a certain operating system.

Mureinik
  • 297,002
  • 52
  • 306
  • 350
  • that makes sense, and seems helpful. my question is more specifically about packages that do work on several platforms _as long as they are built in that specific architecture_. i don't think the os field communicates the answer to "do i need to build this under its runtime architecture if i expect this to work?" question – Joe Fraley Jun 20 '19 at 17:11
0

You can check the package.json for os and also if the package need build like the answer here Node.js / npm - anyway to tell if a package is pure JS or not? But in general, it's not right to install node_modules locally on the host and mount it this against the main idea of docker to run the same image anywhere with zero configuration or dependency

M.Elkady
  • 1,093
  • 7
  • 13
  • many web stacks have fs utilities that you want to run _on the host_. for example, `ember-cli` is a dep of the container runtime for an ember app, but _also_ a developer tool for generating project files. you want to have access to the ember-cli bin on your host and also install it in the container. during development the least tedious answer is to mount the node modules – Joe Fraley Jun 20 '19 at 17:19
  • all this should be inside the container even in development the avoid the well-known issue of "it's working on my machine" – M.Elkady Jun 20 '19 at 17:22
  • if you run the "make me some files" command on the container you get files on the container, but you need them on the host for editing. is that wrong? – Joe Fraley Jun 20 '19 at 17:28
  • the typical scenario for building images for something like ember, react , and angular is to build the application first then copy the result of the build the "dist" to the container then serve by nginx. now the developer can build the image and test it locally and the same image which tested .. can be deployed to production if it's node js app local npm_modules should be in .dockerignore and inside the docker file will be a command for "npm install" what I'm trying to say the main reason of docker is to have the same image with the same behavior without thinking about what is the host . – M.Elkady Jun 20 '19 at 17:36