after Googling around for a few hours on this topic to no avail, I'm hoping someone on here might be able to help clarify this piece of my project for me...
I have a project that has modules that it loads via require() and is able to name them explicitly as they are included in the package.json and have the "main" attribute in their package.json files themselves.
example: require('submodule-name')
The functionality works perfectly, but in each of these modules, I have to require the main file like so: const mainModule = require('../../mainModuleName');
This is so I can access functions and config variables that are attached to the main piece.
I'm wondering if there is a better way to require() this main module without a relative path, since my linter is complaining that the module doesnt exist when I lint the child-module repo on its own. Also, I'd like to employ the use of npm link for future development happiness.
Is there a way of doing this without relative paths? Maybe fix the package.json of the main project file?
UPDATE:
File/folder structure is as follows:
/
mainModule.js
/node_modules
childModule.js <- this requires the mainModule file with a relative path
/modules
anotherChildModule.js <- same relative path requirement of mainModule
I think the problem is in the approach itself. Submodules should not depend on the main modules, as this reverses the dependencies (now the submodule depends on the parent module implementation). I recommend you avoid requiring parent directories, and pass the functions & config to the submodule when you require it instead.
eg: const sub = require('submodule-name')(config)
As an alternative option, NPM supports importing local dependencies therefore you can create a "config" package that you could include in both your sub modules e.g.
package.json
"myconfig": "file:./common"
childModule.js
const config = require('myconfig')
Related
I am using global variable __root with path of my root app directory then I am using require to load code from other files.
const Parser = require(__root + '/parsers/Parser')
The issue is that vscode does not understand what is happening:
Intellisense does not work
Object type is shown as any (if path is correct vscode grabs right type)
What are the options to solve this? Can you share your practices to resolve this issue?
VS Code's intellisense cannot understand dynamic import paths like root + '/path'. There are no workarounds for this, nor are the plans to address this in the immediate future.
However, with static require import paths, you can configure how VS Code resolves the imports by configuring a jsconfig.json. The two options you probably want are baseUrl and paths
Setting up a jsconfig.json will not change the runtime behavior of your code, only how VS Code IntelliSense handles your project. You can use a jsconfig.json along with webpack aliases
hello and today i want to know if i can have only one node_modules folder for all my node js bots, note they are not in app form just single files that use ..... = require('module'); my point is that i have easily more than 7 bots and i go back and forth improving them and maintaining the node_modules folder can be tedius, is there a way where i can have only one folder with all my modules and just do .... = require('path/to/node_modules/module');
or .... = require('path/to/node_modules/'); could someone please point me in the right direction, because when i update my code on my various bots i have to make sure the module is installed, can i have only one node_modules folder???
I can think of these different options:
You can put all your bot files in the same directory and run them all from that directory so all the modules installed in that directory can be used by all the bot files.
You can install all your modules globally.
You could make one shared directory where you installed all the modules and then explicitly point to that every time you want to load a module by referencing that path. This seems less clean because every single user of a module has to know where to load it from.
For each module you want to use in a project, create symlinks to the place where the modules are actually installed. This doesn't seem like it saves any work over just installing the modules again for each bot though.
In another file say myLibs.js you could do something like
module.exports = {
lib1: require('lib1'),
...
libn: require('libn')
}
then in the original file you would do
var myLibs=require('./myLibs.js');
and reference them by myLibs.lib1...
A little clunky, I know, but it should work.
I just want to know one thing,
Consider i have defined a dependency in package.json file like "some-library": "1.0.0"
and installed it using npm install. which will include all dependencies to node_modules folder.
then am importing a Component from that dependency using
import SomeLibrary from 'some-library;
when we do this where this import statement start looking for the component which we are importing ?
can some one explain in a better way. i have googled alot but didn't find any relevant answer. Thanks in advance.
At it's core, the import statement uses the same module resolution method as require().
So for installed modules it goes like this: By calling require(X), it gets a list of all the 'node_modules' directories present in the parent directories. Then, it tries to load the X module from each of those directories (either as a single file, or a directory.)
https://nodejs.org/api/modules.html#modules_all_together
I have a library (ES6) which is composed on many sub-modules, say
- package.json
- lib
- my_package
- file1.js
- file2.js
- sub_module1
- file3.js
- file4.js
I currently do imports like this (all inside my package - using file resolution to find, not node_modules resolution):
import {func1} from 'lib/my_package/file1'
import {func3} 'lib/my_package/sub_module1/file3'
So, in practice I have many files across sub-directories.
I am now trying to package and publish my library, which will be installed under node_modules.
It seems to me that the node resolution algorithm (when behind node_modules) only allows for a single entry point (and there is nothing rollup can do about that)
I would like to be able to include many sub directories and files and for them to be resolved individually.
As far as I understand I have to include a single toplevel file that has all the export from machinery. I can only import that single top level file.
This means having to manually create that file. It also means losing the all the sub-module name structuring that comes from the directory structure.
I was wondering: is there any way one can import any other file from a node_module directly?
Node's resolution algorithm only resolves the first part of a module source, so if someone does this...
var foo = require('your-library/subdir/foo.js');
...then Node (or Browserify/Webpack/rollup-plugin-node-resolve) will correctly resolve that to
/path/to/project/node_modules/your-library/subdir/foo.js
The tricky part is that you want to author JavaScript modules, but if someone is using your library in Node then they need CommonJS modules. Rollup can't help you here — you would need to do a one-to-one ESM->CJS conversion for each module. So that means either using Babel, or authoring CommonJS modules in the first place.
If I have a node.js application that has hundreds of files that reference a module (say underscore) and I want to replace that module with another (say lodash) then the obvious way to do this substitution would be a global name replace and switch out the modules in the package.json file.
Is there anyway to just change the module that a name refers to so that when node.js sees require('moduleA') it actually loads 'moduleB' instead? Now I know that this would cause naming hell because anyone working on the project would see require('moduleA') and wouldn't know that the real module being loaded was 'moduleB' so ultimately you'd probably want to go with the first solution. The use case that I'm thinking of is if you want to try a few alternatives for API compatible modules to measure your application's performance (for example) with each module.
If this is an on-going thing and you want to maintain the ability to programmatically switch between the options often, such as in tests:
Instead of using require("underscore"); throughout your codebase, require a local file instead like require("./lib/underscore");, and have that file conditionally re-export underscore or a different library:
if (global.USE_LODASH) {
module.exports = require("lodash");
} else {
module.exports = require("underscore");
}
If this is a one-off thing to try out an alternative library before making the decision to switch, and you want to do this test quickly first without find-and-replacing in all of your files:
Go inside your node_modules folder, delete or rename the underscore folder, and make a symlink named underscore to the replacement module's folder. I don't recommend this as a long-term solution: running npm install again will likely undo this hack, and most projects choose to avoid checking the node_modules folder into their source repository.
Try to use mock-require module.