In case of a very lengthy built file, I would like to be able to break it into several parts. For instance, the vendors could be all minified into a vendor.built.js file and the rest into an app.built.js file.
How this can be done?
I have a proposed solution for this in my require-lazy project.
It accomplishes something a little different than what you ask though: It splits the application into lazy-loaded modules, as easy (from the developer's perspective) as writing (note the usage of the lazy! plugin):
define(["eager-module", "lazy!lazy-module"], function(eager, lazy) {...})
And then using it with through a promise:
lazy.get().then(function(real_module) {...});
The lazy-module will be loaded once, the first time .get() is called.
For the example above, the build process would produce 2 js files: On containing the main module, the eager-module and all their dependencies. And one containing the lazy-module and all its dependencies that were not included in the previous file/bundle.
The require-lazy project has a few examples that are very simple to setup, you only require Node.js.
Related
Is there a way to find all the places across a project where a particular function is invoked? In particular, taking into account any times that the file is imported.
For example, if we're looking for where library.js's function foobar() is used, this example in another file would be included:
var library = require('./myfile.js')
library.foobar()
(The reason simply searching for foobar across all files won't work is if the function is a common name used in multiple modules.)
This would be the opposite of something like Webstorm's Jump to Definition feature.
One of the use-cases is to help refactor a legacy codebase where it's unclear where certain exported functions are being used, or if they're being used at all.
I saw similar questions like this one, but these seem to be for client-side javascript and don't take exports into account.
You can add
console.trace(); inside your function and you will know where does it called.
Sometime I use callsite module in the function I want to check for log the absolute link to file use this function.
I have a situation where I need to load (via AJAX in a browser) a file that defines a requirejs module (without executing it) and get back a list of its dependencies.
Ie, given a file that starts with
requirejs(["foo/bar", "foo/baz"], function(bar, baz) {
I'd like the utility to return an array like
["foo/bar", "foo/baz"]
I've found some solutions that will do it using r.js (for example, the ones outlined here: https://groups.google.com/forum/#!msg/requirejs/4C0deWFqpZY/mkZFlw2r_k4J), but nothing to do it in a browser. I can just parse out the require statement myself, but that seems suboptimal. Has anyone come across any solutions for this?
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.
I'm new to Node.js.
module.exports = process.env.EXPRESS_COV
? require("./lib-cov/express")
: require("./lib/express");
I know EXPRESS_COV returns a Boolean value, but what is the difference between lib-cov/express and lib/express?
process.env.EXPRESS_COV would be true when you're running tests and want to see the code coverage of those tests (i.e. how many lines of your codebase are actually executed when the tests are run). Mocha, the test framework used for express, achieves this through the use of jscoverage.
JSCoverage parses through your source code and adds a bunch of lines that look like this:
$_jscoverage[filename][line]++;
Naturally, that's rather confusing to have in one's source code, not to mention adding a lot of bulk. So we'd never want JSCoverage processed files in our codebase. Fortunately, JSCoverage places the modified files in a different directory. In this case, ./lib-cov/ instead of ./lib/. That way, we can see how effective our tests are and not clutter up our code.
For details on how this whole rigamarole runs, see TJ Holowaychuk's article.
If you want to avoid all of this, you can use Istanbul instead, as it's much simpler and doesn't require exceptions in index.js
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