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
Related
I've got a very crude implementation working:
var screens = {
a: require('./../react_components/screens/a.jsx'),
b: require('./../react_components/screens/b.jsx'),
c: require('./../react_components/screens/c.jsx'),
d: require('./../react_components/screens/d.jsx'),
e: require('./../react_components/screens/e.jsx')
};
Which works fine, however, I'd like to make it a little more scalable, so that when I change a filename, or add a new file to the /screens folder, I don't really have to keep updating this list of require statements.
I'm using Browserify, so I do have a build step I can hook into if need be (this will be ran in the browser)
So for node/commonjs itself there are modules such as requireindex that will automate this kind of thing. However, the fact that these approaches determine the dependencies at runtime by looking at the filesystem defeats browserify's static analysis so I'm not aware of any of them that are browserify-compatible. Therefore, I'd suggest a code generation route where you use a module such as glob to discover the files you want to export, but then write out a full .js file with the exports all statically coded, and point browserify at that file, which you can regenerate every time during your build step.
In RequireJS documents (http://requirejs.org/docs/api.html#modulename), I couldn't understand this sentence.
You can explicitly name modules yourself, but it makes the modules less portable
My question is
Why explicitly naming module makes less portable?
When explicitly naming module needed?
Why explicitly naming module makes less portable?
If you do not give the module a name explicitly, RequireJS is free to name it whichever way it wants, which gives you more freedom regarding the name you can use to refer to the module. Let's say you have a module the file bar.js. You could give RequireJS this path:
paths: {
"foo": "bar"
}
And you could load the module under the name "foo". If you had given a name to the module in the define call, then you'd be forced to use that name. An excellent example of this problem is with jQuery. It so happens that the jQuery developers have decided (for no good reason I can discern) to hardcode the module name "jquery" in the code of jQuery. Once in a while someone comes on SO complaining that their code won't work and their paths has this:
paths: {
jQuery: "path/to/jquery"
}
This does not work because of the hardcoded name. The paths configuration has to use the name "jquery", all lower case. (A map configuration can be used to map "jquery" to "jQuery".)
When explicitly naming module needed?
It is needed when there is no other way to name the module. A good example is r.js when it concatenates multiple modules together into one file. If the modules were not named during concatenation, there would be no way to refer to them. So r.js adds explicit names to all the modules it concatenates (unless you tell it not to do it or unless the module is already named).
Sometimes I use explicit naming for what I call "glue" or "utility" modules. For instance, suppose that jQuery is already loaded through a script element before RequireJS but I also want my RequireJS modules to be able to require the module jquery to access jQuery rather than rely on the global $. If I ever want to run my code in a context where there is no global jQuery to get, then I don't have to modify it for this situation. I might have a main file like this:
define('jquery', function () {
return $;
});
require.config({ ... });
The jquery module is there only to satisfy modules that need jQuery. There's nothing gained by putting it into a separate file, and to be referred to properly, it has to be named explicitly.
Here's why named modules are less portable, from Sitepen's "AMD, The Definite Source":
AMD is also “anonymous”, meaning that the module does not have to hard-code any references to its own path, the module name relies solely on its file name and directory path, greatly easing any refactoring efforts.
http://www.sitepen.com/blog/2012/06/25/amd-the-definitive-source/
And from Addy Osmani's "Writing modular javascript":
When working with anonymous modules, the idea of a module's identity is DRY, making it trivial to avoid duplication of filenames and code. Because the code is more portable, it can be easily moved to other locations (or around the file-system) without needing to alter the code itself or change its ID. The module_id is equivalent to folder paths in simple packages and when not used in packages. Developers can also run the same code on multiple environments just by using an AMD optimizer that works with a CommonJS environment such as r.js.
http://addyosmani.com/writing-modular-js/
Why one would need a explicitly named module, again from Addy Osmani's "Writing modular javascript":
The module_id is an optional argument which is typically only required when non-AMD concatenation tools are being used (there may be some other edge cases where it's useful too).
I write a fairly complicated node.js project, and the need to write the relative path in the "require" is driving me insane and is error prune.
Is there any way to avoid stuff like this
logger = require('../../modules/logger');
and be path-independent without turning every module into a full blown npm module?
I often use an "app symlink" where I create a symlink at node_modules/app that points to ../app. Then in my code I can require modules without relative paths: require('app/logger'). It avoids lots of ../../.. paths and having to change them when you move a file around. However, since it relies on symlinks and Windows does not support symlinks, it won't work on Windows. Thus I only use it in apps I know only need to work on posix systems.
Depending on how your directory structure is laid out for your project, it might be best to pass things like your logger to your other modules from the main app (and farther from there).
var logger = require('./helpers/logger');
var someModule = require ('./controllers/someModule')({ logger: logger });
Passing other things that way help too, like the db connection (or connection pool). Again, depends on how you have your project laid out.
Are there any known issues with mixing nodejs modules (require) with typescript definition files (d.ts) multiple times over files within a module?
My scenario is that I have a module namespace per folder (much like I would in C#), then I basically compile them all via tsc to an outputted my-module.js. However I keep getting really odd errors like Could not find type HTMLElement but lots of people have pointed out that tsc includes the typescript lib file by default which contains all those types.
I have noticed a few people having odd errors when they are including the same d.ts files over multiple files which are all compiled with the --out flag to get it all into one file, so could this be causing my issues?
An example of my usage would be:
///<reference path="path/to/knockout.d.ts" />
import ko = require("knockout");
This would then be put in each file which requires knockout js, which is at least 10 files in the module i'm trying to compile currently. It just bombs out constantly saying knockout.d.ts cannot find the type HTMLElemet, Element, Document etc.
If you are using external modules (which you are if you have a top level "import" - as shown above), then you can't use the --out switch to combine multiple source files. It is a limitation that with external modules that one source file = one module. With source that is not in an external module (i.e. contributes to the 'global' scope), you can combine input source to one output JavaScript file using --out.
I have no idea about the "could not find HTMLElement" issues. If you can provide a repro (and outline which version you are using) I can take a look.
I'm using Node and Express and I have a very beginner question. In fact it's so basic that I'm having trouble coming up with a title for it. I'm writing a modular piece of logic. It involves a few javascript files and I'd like to keep them together in one directory. When I person goes to my web app, this code is to be accessed from routes/index.js. I want to have something like
var foo = require('???/logic');
and then when somebody loads the page I will call
foo.getBar();
and then assign what it returns to a variable used in the jade template
So my questions are 1. Where should I put my directory of modular code? node_modules? and 2. Does this, generally, sound like the right way to design an express app?
Choose from the structure below based on the amount of code we are talking about.
A: single CommonJS module in a single .js file
You can export functions, constructor functions, properties
if you have 30 properties exported or more than X lines of code (for me X is 300ish, for others they are OK with 500ish), graduate to the next option
B: CommonJS module directory consisting of a my-module/index.js and other supporting .js files
other modules can require this with require('./my-module') and not know or care whether my-module is 1 .js file or many in a directory
Use this variant as your logic grows
loose coupling. High cohesion.
C: Put your logic in it's own npm module
This makes it shareable with the community and across your internal projects as well
The better you get at this and more comfortable with the process and tools, the more likely you are to skip A and B and just make standalone npm modules