CODEWITHSUNDEEP
javascriptangularjsnode.jsgulpbrowserify
Grateful
Grateful

Reputation: 10175

Why the need for browserify `paths` definition?

The link https://github.com/jhades/angularjs-gulp-example/blob/master/gulpfile.js has the gulp build-js task definition using browserify paths. I don't understand the need for it... wasn't it possible just to specify the entries as entries: './js/**/*.js', and this would have caused it to search all the sub-directories as well... instead of explicitly specifying paths: ['./js/controllers', './js/services', './js/directives'], which are all sub-directories of the same parent?

Any hints appreciated.

Upvotes: 2

Views: 225

Answers (2)

Grateful
Grateful

Reputation: 10175

Well, one simple answer seems to be the fact that **/* is not recognised by browserify! You would have to require("glob") to do that... but it's probably simpler just to use paths to specify the extra folders.

Upvotes: 0

cartant
cartant

Reputation: 58400

The author is using the paths configuration to enable non-relative require calls like these:

require('todoCtrl');
require('todoStorage');
require('todoFocus');
require('todoEscape');
require('footer');

Browserify emulates Node's module resolution mechanism (which is explained here) and when Node resolves a non-relative require, it looks in node_modules. The paths option gives Browserify a list of paths that are not in node_modules that it should check (before checking node_modules) when attempting to resolve non-relative require calls.

If all of your require calls for modules in your own project use relative paths (e.g. require('./js/controllers/todoCtrl')), you won't need the paths configuration option.

Upvotes: 2

Related Questions