I'm requiring an module that has already been required in another file, but when I get the object, many of it's keys are undefined. A bunch of the keys are there, but some are not, even after I call some of the exposed functions. If I console.log the object, the keys look like they are there.
Example:
var mod = require('myModule')
console.log(mod) // { 'aKey':[Function], 'doStoff':[Function] }
console.log(mod.aKey) // undefined
mod.doStoff() // calls 'aKey'
//TypeError: Object #<Object> has no method 'aKey'
//this error is thrown inside myModule
This would not overly surprise me if this module was doing something goofy when it get's loaded, but the module has already been loaded and I have used it for several things already in the main js file.
The only thing I can think of that is off the norm: I've required this module in the main js file (and it works), but the place that it does not work is inside a module that is required in the main.
To be clearer->
main.js requires myModule
main.js requires otherModule
otherModule requires myModule
myModule was installed by npm, but I'm prototyping the otherModule in place in the node_modules folder until I get it put up somewhere so npm will install it.
I don't see why this would cause a problem; I thought that the object that gets returned from require gets kept in the require cache--as is--so that when it gets required any time afterwards you get that same object. It seems that my object has been partially deleted or something.
What is causing this? What should I do differently?
I have found why I was having these issues:
When node tries to resolve the path for require('myModule', it will walk down the directory path from the position of the current module. If you have a symbolic link as a directory in your node_modules folder, nodejs will not follow that link back to your own node_modules folder--it will just walk down the directory path looking for your module. I had a symbolic link in there to help me keep my modules that are under development in a place I could easily test them. I'm not sure at what point I put that link in, but I didn't think it was important.
Since the require did not resolve to the same path for me, I kept getting a fresh load of the module, instead of the one in the require cache.
I am not sure why I got the symptoms I did originally (with certain keys being missing sometimes), but since I had a broken setup I guess I found some unexpected behavior.
Related
I know that this must be a really basic problem, but I've never really learned what to do with node modules after you npm -i them. Every time I try to reference a js or css file in node modules, I get a 404 error, so I've been moving the needed src files into my static folder and importing/using them from there.
Problem is, now I've run into a complex enough package, that this (hacky?) solution doesn't work, the files relatively reference each other a LOT and I would have to go in and update all the references. Not to mention, even if I do change all the references, I also have to add the file extensions, because it doesn't seem to find them automatically, even for .js files, which I'm not sure I understand.
Also this solution leaves me with a folder structure like
node_modeules
--> package
----> src
------>js
--------> file.js
public
--> javascripts
---->file.js
which feels like a poor use of disk space, since I'm doubling up on files.
So my question is, how should I be importing node_module packages and using them?
We have a node project that does not require our own submodules from a relative path, but instead needs the NODE_PATH environment variable be set to lib to find all submodules.
I wanted to handle this standard case within the program source code but it seems like it is impossible by now.
I found several solutions which all do not work as expected.
module.paths.push("./lib");
Was suggested in another stackoverflow article but this causes an error message in the newer Node versions and refers the developer to using NODE_PATH.
Instead I tried to do the following as the very first line of my program.
process.env['NODE_PATH']="./lib";
This does not cause an error message but it does not work either. I think that this variable is read on the application start and not read lateron when requiering stuff.
All information you can find out from the source: module.js
... NODE_PATH error is thrown only when accessing via require.paths.
Search for _nodeModulePaths function: Module instance has generic Array object paths, with all lookup paths in it.
module.paths.unshift('./foo-baz');
var x = require('some-lib-name');
console.log(x);
So now, if you have the required module under ./foo-baz/some-lib-name/ it would be properly picked up.
What node version and what system you have?
Backstory:
I've currently got a Require.js and jQuery/Backbone.js using site. Until now, jQuery and Backbone have stayed outside of Require, letting me do:
define([], function() {
// NOTE: Using Backbone and $ without an import!
new Backbone.View(el: $('#foo');
});
That's worked really well: without that approach, just about every module in my site would have to add a Backbone/jQuery dependency.
But then the other day I needed to package up a portion of our code as an external library. I made a separate require config file for it, and everything seemed great, until I compiled ("optimized") all the files in to a single library file, and realized that Backbone/jQuery (and related plug-ins/libraries) weren't getting included.
So, I added a bunch of shims, and got Backbone, jQuery, and all the related libraries in to Require. However, I still have a ton of modules that expect $ and Backbone to just exist. That should be ok, because Backbone/jQuery both register their variables globally, but it's not because of Require's load order.
Basically, any module without dependencies is broken, because they load before Require loads the jQuery/Backbone shim. Any modules that have dependencies don't have this issue, because jQuery/Backbone have already been loaded by the time they get loaded.
It seems like my only option is to add an explicit Backbone/jQuery to every module without dependencies. I've got a bunch of modules like that though, and ideally I'd prefer not to have to import jQuery/Backbone anywhere.
Question
So, my question is: is there any way to tell Require "load these X modules/shims before you load everything else"? Or, to put it another way, is there any way to tell Require that all of my modules depend on certain other modules?
I thought putting Backbone at the top of my initial require:
require(['backbone', ...
but that didn't help; the other dependency-less modules still load before it.
I see no reason this would not work:
require(['backbone', 'jquery'], function () {
require(['main']);
});
The idea is to wrap what was your initial entry point to your application in a require call that loads Backbone and jQuery. If the modules of your application are loaded only because main is required (that is, if there is no require call elsewhere that loads any module needed by main), then with the code above both Backbone and jQuery are guaranteed to be loaded before any of the modules used by main are.
I'm just getting started with Component package manager. I understand that I can require in other local modules by adding the module to the local key in the component.json file, but what if I don't want to treat every file as a module?
In the (very minimal) documentation for Component, it's developer TJ says that I can add any other relevant scripts (that live in the same directory) to the scripts array. And yet, on doing so, I'm unable to require or reference any of the peripheral scripts' methods from my main file.
The require method fails on trying to load in the script, and any attempt to reference the methods or variables from that script from the 'bootstrap' file are futile. My build.js shows that the script has been compiled in, but I just can't seem to figure out the correct way to reference it from other scripts...
Help?
I just thought I'd post the answer to this question so anybody with the same problem can find it quickly/painlessly.
The answer is to reference the script with a pointer to it's current directory like so:
var script = require('./script.js');
Note the ./ at the beginning of the file name.
An easy mistake to make/rectify.
I'm working on a large Node project. Naturally, I want to break this into multiple source files. There are many modules from the standard lib that I use in a majority of my source files, and there are also quite a few of my own files that I want to use almost everywhere.
I've been making this work by including a huge require block at the beginning of each source file, but this feels awfully redundant. Is there a better way to do this? Or is this an intended consequence of Node's admirable module system?
You can use a container module to load a series of modules. For example, given the following project structure:
lib/
index.js
module1.js
module2.js
main.js
You can have index.js import the other modules in the library.
# index.js
module.exports.module1 = require('./module1');
module.exports.module2 = require('./module2');
Then main.js need only import a single module:
# main.js
var lib = require('./lib');
lib.module1.doSomething();
lib.module2.doSomethingElse();
This technique can be expanded, reducing redundant imports.
I'd say generally that a require block is better practice than using global in Node.
You need to remember that requires are cached so when you put them in all of your code modules, you will always get the same instance not a new one each time.
Doing it this way ensures that you get the appropriate code with the expected name spaces exactly where you want it whereas using global will include things you don't need. Doing it the Node way with require will also tend to make your code slightly more portable.
Well, a couple of things, here.
First, if so many of your files are requiring the same libraries over and over again, you might want to step back and determine if you're really breaking your code up in the proper way. Perhaps there's a better organization where certain libraries are only needed by subsets of your source files?
Second, remember that the global object is shared between all of your required files in your Node.js app. Your "root" source file, say index.js, can do things like global.fs = require('fs'); and then it's accessible from all of your various files. This would eliminate the need to require a file full of requires. (In Node.js, you have to explicitly state that you're accessing a global variable by prepending global., unlike in the browser.)
This can be a good idea for CRUD-type Express apps where you have lots of code for controllers that are all almost the same but have to be slightly different for each view and you just want to split them apart not for any particular organization structure, but just to make it easier to debug (error in this file, not that file). If the structure of the app is more complex than that, take the usual warnings against global variables to heart before using that trick.
Require more than one file without absolute path through require-file-directory.
1- Can require more than one file in single statement.
2- Can require files with only their name.
Visit for solution: https://www.npmjs.com/package/require-file-directory