Browserify with paths to folders in my system

When I compile markdown-symbols using Browserify 3.30.2 (browserify file.js -o bundle.js), I get something like that :

!function(e){if("object"==typeof exports...[function(_dereq_,module,exports){

[on line 8000] 
    : function (str, start, len) {
        if (start < 0) start = str.length + start;
        return str.substr(start, len);

var frep = _dereq_('frep');
var file = _dereq_('fs-utils');
var delims = _dereq_('delims');
var _ = _dereq_('lodash');

As you can see, there are absolute paths to my files here. Why ? How can I remove them ?

EDIT: here is my build.js file

 var browserify = require('browserify-middleware')
fs = require('fs');
var b = browserify('./index.js', {
    'opts.basedir': './'
    // Mocks up express req and res
    headers: []
}, {
    getHeader: function () {},
    setHeader: function () {},
    send: function (a) {
        console.log('send', a);
    end: function (a) {
        //  fs.write('bundle.js', a, undefined, undefined, function (err) {
        //  a.pipe(fs.createWriteStream('bundle.js'));


And to run node build > bundle.js. same problem. If I replace basedir value by for instancee ihatebrowserify there is an error about something not resolved.

This came across to me as well today. It turns out there’s a boolean option --full-path[0] now that solves the problem.

For example:

browserify -o bundle.js --full-path=false index.js


Almost 6 months later, and I’ve seen the same issue. Now I found a workaround that suited me, and others might benefit from it as well.

Google has given me this issue report: — which reports this local system path disclosure on “browserify-shim”, although it is a “browserify” issue from what I understood.

That issue suggests an workaround:

$ npm install -g intreq browser-pack browser-unpack
$ browserify example/main.js -t browserify-shim | browser-unpack | intreq | browser-pack

I’ve tested this and was satisfied with the results. However I wanted to go further, and integrate this into my Gruntfile.js. The solution I found, tested and that made me happy is to use unpathify:

Compress browserify require paths for better minification i.e. require(‘some/long/path’) => require(1)

To use it, just install unpathify (npm install --save-dev unpathify) and add it to your build:

  browserify: {
    all: {
      files: {
        'build/all.js': ['some/file.js']
  unpathify: {
    all: {
      src: ['build/all.js']
  // ...

Browserify resolves absolute path as default. If you do not want to see absolute paths, you can set options.basedir as you want. For example;

var browserify = require('browserify-middleware');
var b = browserify({'opts.basedir': './'});

My best guess is that somewhere, there are modules being included from absolute paths.

Read More:   Variable assignment inside an 'if' condition in JavaScript

It doesn’t happen to me when using browserify.

Actually it’s more than a guess.


You have _dereq_("C:\\Users\\Me\\AppData\\Roaming\\npm\\node_modules\\browserify\\node_modules\\insert-module-globals\\node_modules\\process\\browser.js"); therefore, it must include that module.

If you set some Node global (no idea how on Windows) to look in C:\\Users\\Me\\AppData\\Roaming\\npm\\node_modules, you might not have to include the full path, but i can’t be sure.

Not entirely sure if this is an answer to the original question, but I was having a similar problem. The bundled js file and the external sourcemap (using exorcist) being generated was containing absolute paths to folders on my system. After a headache figuring out why, it seems the culprit was babelify (previously 6to5ify). &

The solution is simple though:

browserify –debug -t [ babelify –sourceMapRelative . ]


browserify({ debug: true })
.transform(babelify.configure({sourceMapRelative: ‘.’ }))

There is a new Browserify plugin available from the author of Browserify. It’s called Bundle-Collapser. It’ll replace folder paths with numerical indices.

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Similar Posts