When unit testing, I tend to have a directory called test at the top of my project structure, with the directory structure mimicking the source code that is to be tested. However, these directories can get quite deep, for example
app/src/js/models/User.js
with perhaps a test in
test/app/src/js/models/User.js.
Now, when I want to include the User.js module, I use require('../../../../../app/src/js/models/Users.js') which is very cumbersome.
Ideally, I would like to use require('/app/src/js/models/User.js') or perhaps even require('User.js').
Is this possible? I am using grunt-mocha-test, but I think the question is a more general one.
There are multiple options you could use. Your best bet would probably be to use some npm module, for example this one. Search the npm registory for require, there are tons of options so choose whichever suits your needs.
Alternatively, you could write some helper function that does something similar.
If you were looking for some native way (built-in to Node.js) to achieve this, sadly there are none. You will have to use either a custom function or an npm module to do this in some nice, reusable way.
Related
I'm setting up a build system using node modules and npm scripts - no gulp, etc.
I need to determine if two files are equal, before copying unnecessarily. When I used to use gulp I used the gulp-changed plugin. I need something like that.
How could I do this in plain node?
I couldn't find an existing npm module that does this. I also checked the fs module but didn't find anything I could use.
I need something like this: function hasChanged(file1, file2) { /* ... */ } but I'm not sure how to compare the files.
UPDATE
Using the advice given so far, this problem seems simple enough to code myself, so I'm doing that. But if you know of a node module that does this already, I'd appreciate it.
You might use fs.stat function to get file info, and compare mtime to see if they differ. I also recommend you to lookup the sourcecode of gulp-change, its actully just a few lines of code.
https://github.com/sindresorhus/gulp-changed?files=1
Do you try use fs.watch.
It is still possible to use fs.watchFile(), which uses stat polling, but this method is slower and less reliable.
If you want check 2 file, try using hash code of them with md5.
I'm writing a Perl script that takes data and writes it to an Excel file. I'm using Excel::Writer::XLSX to do this.
I'm hoping to write the script and then give it to the rest of my team so we can all use it to compile the data when we need to.
I have a few questions about this:
Do my colleagues need to have the module installed to for the script to work?
If not, how do I wrap up the module with the script to give it to them?
Is there a better way of doing this that using the module I've chosen?
There are a few ways of doing this. One options is to put together a Makefile.PL that specifies the dependencies. This allows you to bundle your script as a distribution. E.g.
use ExtUtils::MakeMaker;
WriteMakefile(
ABSTRACT => 'myscript creates Excel files',
AUTHOR => 'A.U. Thor',
EXE_FILES => [ 'myscript' ],
NAME => 'myscript',
VERSION => '1.2.3',
PREREQ_PM => {
'Excel::Writer::XLSX' => '0.88',
},
);
Then, people can do perl Makefile.PL which will inform them of the dependencies. If you do make dist, and distribute the resulting archive file, they can also use cpanm to install your script along with its dependencies.
Another option is to put together a cpanfile. Then, recipients can install all the dependencies using a tool such as cpanm.
Now, if you are distributing the script to people who do not use Perl normally, and you want them to be able to just click and run etc, you might want to look into pp.
A long time ago, I wrote a program I called scriptdist to turn a single-file program into a CPAN-like distribution, complete with a build file. That way you could pass it around as an archive and people could treat it like any other CPAN distribution. It basically automates what Sinan posted. I wrote about it for Dr. Dobbs.
There's a trick that you can use if you want to pass around the archive. The cpan tool can install from the current directory. That will get the dependencies (which, by the nature of being dependencies, are required):
$ cpan .
That way, you can install your program and its dependencies without putting anything in a CPAN-like repository.
It's far from clear what you need to know
Do my colleagues need to have the module installed to for the script to work?
I think it's obvious that your colleagues need access to your code to be able to make use of it
It's not clear what you have written, but if you have created a module then any program with access to your module files can simply use it to access its capabilities
If not, how do I wrap up the module with the script to give it to them?
Your "if not" isn't clear. What you have written means "If they don't need to have the module installed to for the script to work", and I doubt if that is your intention
"how do I wrap up the module with the script" Are you asking how to create a module, or do you already have one? Typically, modules are accessed by programmers who write a script with the use statement
If you have a module and you want other people to be able to load it with use then it must appear in one of the directories listed in their #INC array. If you are working on separate systems then it is best to create a package that you can alter as necessary and have others update
Is there a better way of doing this (than) using the module I've chosen?
Are you referring to Excel::Writer::XLSX or your own module?
If Excel::Writer::XLSX is doing what you need then you probably shgouldn't change. But if you are having problems with it in some way then you need to ask a new question and describe those issues
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 was wondering whether Node.js/npm include any kind of exension mechanism comparable to Python setuptools' "entry points".
So, in short:
is there any way I can do dynamic discovery of services provided by other packages using npm?
if not, what would be the best way to implement something similar? Specifying the extension name in the main module's configuration file seems to be the logical solution, but I wonder whether something "automatic" can be done.
I'm not aware of any builtin mechanism to do this.
One viable way of doing it yourself:
I made a small tool (Jumpstart) to quickly create project scaffolding from templates with placeholders, and I used a kind of plugin mechanism for that. It basically comes down to that the Jumpstart script searches for modules named jumpstart-* "adjacent" to where the module itself is installed. So it would work for both local and global installations. If installed locally, it would search the other local modules (on the same level) and if global, it searches the other global modules.
Note that here, "search" comes down to a simple fs.exists check to see if there's a Jumpstart template module with a particular name installed. However, nothing would stand in the way to actually get a full list of all installed packages matching the jumpstart-* pattern, and loading all at once. I could also search up the entire directory tree for node_modules directories and do the same. There's no point in doing this for this particular program, however.
See https://npmjs.org/package/jumpstart for docs.
The only limitation to this technique is that all modules must be named in a consistent fashion. Start with some string, end with some string, something like that. Any rogue packages polluting the namespace could be detected by doing further checks on a package contents: What files does it contain? What kind of object does its main module export? etc.
Brunch also uses a plugin mechanism. This one actually deals with file extensions, so is more relevant: https://github.com/brunch/brunch/wiki/Plugins . See for example source of the CoffeeScript plugin https://github.com/brunch/coffee-script-brunch/blob/master/src/index.coffee .
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