Specify node_modules directory in .importjs.js
mnieber opened this issue · comments
Since I'm running my code in Docker (but editing my code on the host computer), my node_modules directory is not in the directory that has package.json. This means that imports from node_modules are not found. Therefore, it would be great if I could specify node_modules_dir in .importjs.js.
By the way, this would perhaps also provide an alternative solution to the problem that is now solved with adding "importjs": { "isRoot": false } to package.json. This would be the case if package.json is only used to locate node_modules. With my proposal, the correct location could be specified directly in .importjs.js.
Could you explain the directory structure a little? I'm trying to understand if this is a docker issue or more an issue with not having node_modules in the root of the project.
While there are references to "node_modules" scattered around in the codebase, I believe the package-finding logic will mostly just look in the package.json file:
https://github.com/Galooshi/import-js/blob/master/lib/findPackageDependencies.js
Sure. I currently have a docker volume with node_modules that is mounted into the docker container. Although this docker volume is just a directory (inside the global docker directory) on the host, it can't be used directly by importjs because it's owned by root.
My plan was therefore to use a volume-mapping from a node_modules directory (owner by user) to the docker container. I could put this node_modules directory next to package.json but I would rather not do that because it would pollute the source directory (I don't need to have node_modules there because I'm not using it on the host). But it's not too bad, so I will go with that for the moment. Still, it would be nice to have the possibility of specifying node_modules in .importjs.js (also because "isRoot" may not always be scaleable, since in some contexts the package.json could be root and in others it may not be).
In any case, thanks for creating importjs, it's very helpful.
Thanks! Glad you found a workaround at least. Let's keep this issue open until we have a proper solution in place. I won't be taking this on as it's not a feature I would be using (that's the general philosophy we have running this project) but I'd be happy to review a PR adding support for this.