jmreidy / grunt-browserify Goto Github PK

Hello,

I'm using grunt-browserify to bundle game files but i'm getting this error:

Running "browserify:release" (browserify) task
>> Error: Cannot find module './core/globals'
Warning: Error running grunt-browserify. Use --force to continue.

I really don't know what is this './core/globals' module.

Here is my configuration files:

Gruntfile.js

module.exports = function (grunt) {
  'use strict';

  var banner = [
    '/**',
    ' * <%= pkg.name %> <%= pkg.version %>',
    ' * <%= pkg.homepage %>',
    ' * Copyright (c) 2013 Luiz de Prá (AKA RawArkanis) http://luizdepra.com.br',
    ' * <%= pkg.description %>',
    ' * built on: ' + new Date(),
    ' */',
    ''].join("\n");

  grunt.initConfig({
    // Configs
    pkg: grunt.file.readJSON('package.json'),
    dir: {
      build: 'build',
      src: 'src',
      js: 'js',
      css: 'css',
      res: 'res'
    },
    bundle: {
      dev: 'pixilife.js',
      release: 'pixilife.min.js'
    },
    // Clean
    clean: ['<%= dir.build %>/*'],
    // Copy
    copy: {
      main: {
        files: [
          {expand: true, flatten: true, src: ['<%= dir.src %>/*'], dest: '<%= dir.build %>/', filter: 'isFile'},
          {expand: true, flatten: true, src: ['<%= dir.src %>/<%= dir.css %>/**'], dest: '<%= dir.build %>/<%= dir.css %>/'},
          {expand: true, flatten: true, src: ['<%= dir.src %>/<%= dir.res %>/**'], dest: '<%= dir.build %>/<%= dir.res %>/'}
        ]
      }
    },
    // JSHint
    jshint: {
      options: {
        jshintrc: 'jshintrc'
      },
      src: {
        src: [
          'Gruntfile.js',
          '<%= dir.src %>/**/*.js'
        ],
        options: {
            ignores: ['<%= dir.src %>/<%= dir.js %>/<%= bundle.dev %>']
        }
      },
      dev: {
        src: '<%= dir.src %>/<%= dir.js %>/<%= bundle.dev %>'
      }
    },
    // Uglify
    uglify: {
      options: {
        banner: banner
      },
      release: {
        options: {
          wrap: true
        },
        files: {
          '<%= dir.build %>/<%= dir.js %>/<%= bundle.release %>': '<%= dir.build %>/<%= dir.js %>/<%= bundle.release %>'
        }
      }
    },
    // Browserify
    browserify: {
      dev: {
        files: {
          '<%= dir.src %>/<%= dir.js %>/<%= bundle.dev %>': ['<%= dir.src %>/<%= dir.js %>/**/*.js']
        }
      },
      release: {
        files: {
          '<%= dir.build %>/<%= dir.js %>/<%= bundle.release %>': ['<%= dir.src %>/<%= dir.js %>/**/*.js']
        }
      }
    },
    // Connect
    connect: {
      server: {
        options: {
          port: 4321,
          base: '<%= dir.src %>',
          keepalive: true
        }
      }
    }
  });

  // Load Tasks
  grunt.loadNpmTasks('grunt-browserify');
  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.loadNpmTasks('grunt-contrib-clean');
  grunt.loadNpmTasks('grunt-contrib-copy');
  grunt.loadNpmTasks('grunt-contrib-connect');

  // Register Tasks
  grunt.registerTask('default', ['build']);
  grunt.registerTask('build', ['clean', 'copy', 'jshint:src', 'browserify:release', 'uglify:release']);
  grunt.registerTask('build-dev', ['jshint:src', 'browserify:dev']);
  grunt.registerTask('server', ['connect:server']);
};

jshintrc

{
    "passfail"      : false,
    "maxerr"        : 0,
    "browser"       : false,

    "node"          : false,
    "rhino"         : false,
    "couch"         : false,
    "wsh"           : false,

    "jquery"        : false,
    "prototypejs"   : false,
    "mootools"      : false,
    "dojo"          : false,

    "predef"     : [
        "require",
        "exports",
        "module",
        "document",
        "requestAnimationFrame"
    ],

    "debug"         : false,
    "devel"         : false,

    "es5"           : false,
    "strict"        : false,
    "globalstrict"  : true,

    "smarttabs"     : false,
    "asi"           : true,
    "laxbreak"      : false,
    "bitwise"       : false,
    "boss"          : false,
    "curly"         : false,
    "eqeqeq"        : false,
    "eqnull"        : true,
    "evil"          : false,
    "expr"          : false,
    "forin"         : false,
    "immed"         : true,
    "latedef"       : true,
    "loopfunc"      : false,
    "noarg"         : true,
    "regexp"        : true,
    "regexdash"     : false,
    "scripturl"     : true,
    "shadow"        : false,
    "supernew"      : false,
    "undef"         : false,

    "newcap"        : true,
    "noempty"       : true,
    "nonew"         : false,
    "nomen"         : false,
    "onevar"        : false,
    "plusplus"      : false,
    "sub"           : false,
    "trailing"      : true
}

And my main.js:

"use strict";

var pixi = require('pixi');

var renderer = pixi.autoDetectRenderer(800, 600);
document.body.appendChild(renderer.view);

var stage = new pixi.Stage(0x66FF00);

function animate() {
    renderer.render(stage);

    requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

You can find it all here: https://github.com/RawArkanis/PixiLife

What I'm doing wrong?

I don't know how come no one posted this yet, but the very basic task fails half of the time because of the async issue:

browserify: {
  'destFile.js': ['srcFile.js'];
}

Sometimes the output destFile.js will be incomplete (missing a few characters). I have manually written a test browserify code and the error is most probably in forEachSeries. Here's something that might help:

http://gruntjs.com/api/inside-tasks

I tried to fix but I wasn't sure where the done() function should go.

(P.S. that was so painful to track down lol, the task success half of the time and doesn't throw errors, and the browser simply says require wasn't available.)

I'm posting this issue to let you know that we will be publishing Grunt 0.4 on Monday, February 18th.

If your plugin is not already Grunt 0.4 compatible, would you please consider updating it? For an overview of what's changed, please see our migration guide.

If you'd like to develop against the final version of Grunt before Monday, please specify "grunt": "0.4.0rc8" as a devDependency in your project. After Monday's release, you'll be able to use "grunt": "~0.4.0" to actually publish your plugin. If you depend on any plugins from the grunt-contrib series, please see our list of release candidates for compatible versions. All of these will be updated to final status when Grunt 0.4 is published.

Also, in an effort to reduce duplication of effort and fragmentation in the developer community, could you review the grunt-contrib series of plugins to see if any of your functionality overlaps significantly with them? Grunt-contrib is community maintained with 40+ contributors—we'd love to discuss any additions you'd like to make.

Finally, we're working on a new task format that doesn't depend on Grunt: it's called node-task. Once this is complete, there will be one more conversion, and then we'll never ask you to upgrade your plugins to support our changes again. Until that happens, thanks for bearing with us!

If you have any questions about how to proceed, please respond here, or join us in #grunt on irc.freenode.net.

Thanks, we really appreciate your work!

As soon as I add the noParse option I get this error in the browser:

Uncaught ReferenceError: global is not defined

Here's my config:

var vendor = {
  jquery: 'bower_components/jquery/jquery.js',
  handlebars: 'bower_components/handlebars/dist/handlebars.runtime.js',
  ember: 'bower_components/ember/ember.js'
};

module.exports = {
  build: {
    src: [
      vendor.jquery,
      vendor.handlebars,
      vendor.ember,
      'tmp/public/assets/templates.js',
      'tmp/transpiled/app/index.js'
    ],
    dest: 'tmp/public/assets/app.js',
    options: {
      noParse: [
        vendor.jquery,
        vendor.handlebars,
        vendor.ember,
        'tmp/public/assets/templates.js'
      ],
      debug: true,
      shim: {
        jquery: {
          path: vendor.jquery,
          exports: 'jQuery'
        },
        handlebars: {
          path: vendor.handlebars,
          exports: 'Handlebars'
        },
        ember: {
          path: vendor.ember,
          exports: 'Ember',
          depends: {
            'ember-imports': 'Ember',
            jquery: 'jQuery',
            handlebars: 'Handlebars'
          }
        }
      }
    }
  }
};

Unless I'm Doing it Wrong™, I've noticed that aliasMappings don't get the same treatment as alias files as automatically externalized for other bundles in the post #83 world. This would be super useful.

Now, i cann't externalize 'foo/bar.js' becouse it exposed as '/home/a.rublev/work/project/foo/bar.js' if i provide same alias as require id.

I want simple, easy way to use browserify's require(id, {expose: id}) or just require(id) in grunt-browserify for project files.

I'm trying to improve my overall workflow by using something like requireindex instead of having to manually maintain my index.js entry points (which sucks if module names or locations ever change).

However, this doesn't seem to play with grunt-browserify; the bundle just ends up spitting out everything related to requireindex and browserify's Node I/O shims, but the actual modules I want required are not included.

Am I going about this the wrong way? How can I browserify a "dynamic" entry point with grunt-browserify?

EDIT: More specifically; I cannot just use lib/**/*.js as my src files since I am trying to do this for a standalone UMD build (which requires a single entry point).

How I can expose foo/bar.js exactly as './foo/bar.js' (without resolving relative paths to fullpath) ?
I need for some pathnames for modules on client and server-side.

Hi all. I think I am missing something. With this config:

library:{
  src:[],
  options:{alias: ["common/lib/module.js:lib/module"]}
},
consumer:{
  src:["app/some/file.js"],
  options:{external:["common/lib/module.js"]
}

If file.js references require("lib/module") the task fails because it cannot find lib/module. It only works if I reference the path, i.e. ../../common/lib/module. If I just open a browser console require("lib/module") works. But app/some/file.js always has to use the whole relative path to complete the grunt task. I tried adding alias:["common/lib/module.js:lib/module"] to consumer like the external example, but no luck. I may not understand the purpose of the feature. Someone please enlighten me!

t.

According to the docs, the basic usage is:

browserify: {
src: [‘client/scripts/*/.js`],
dest: ‘build/module.js’
}


But it seems that doing so tries to write the output to 'src' and fails since the directory exists:

$ grunt -v browserify
...
Running "browserify" task
Running "browserify:src" (browserify) task
Verifying property browserify.src exists in config...OK
Files: src/HelloWorld.js, src/jsml.js -> src
Fatal error: EISDIR, open 'src'


Changing the code to use a sub-task (multitask? Not sure about grunt terminology) as follows resolves that:

This is a pretty straightforward solution, but the docs for the simplest use case are confusing, and took me a while to figure why I get the error message.
Thanks!

(grunt-cli v0.1.8
grunt v0.4.1,
grunt-browserify 1.0 (installed 10/5/2013)
)

$ browserify -t coffeeify coffee/app.coffee > test.js

results in

coffee/app.coffee:18
        $timeout -> context.update(key), 0 unless _.isEqual e1[key], e2[key]
                                 ^
ParseError: unexpected ,

However if running it as a grunt-browserify task with coffeify transform, I get something like

Running "browserify:dist" (browserify) task
Warning: unexpected , Use --force to continue.

Aborted due to warnings.

There is no file, no line number. How is one supposed to figure out where the compilation error occurred?

Hello
when using browserify on the command line we are allowed to use nodejs style module names and with modules like bowerify and amdify to use the module name of modules packadged as bower components or amd style components.

Is this possible with grunt-browerify, i.e. if I did
npm install 'handlebars' , am I allowed to write
src : ['handlebars'] or shall I write
src : ['node_modules/handlebars/lib/handlebars.js'] (not nice)

right now I seem to get grunt-browserify working only with the second way and can't seem to properly use the effects of bowerify but I might do something wrong.
The example I saw only seem to use .js paths.

Said otherwise does the 'src' param behave identically to the require() call interpreted by bowerify or not :)

thanks a lot for your time.

Setting insertGlobals: true causes the following error when I run the task:

Fatal error: Arguments to path.resolve must be strings

My config is:

            dev:
                src: ['src/app/bootstrap.coffee']
                dest: 'build/js/app.js'
                options:
                    transform: ['simple-jadeify', 'coffeeify']
                    debug: true
                    alias: ['jquery-browserify:jquery']
                    aliasMappings: [
                        {
                            cwd: 'src/app'
                            src: ['**/*.jade', '**/*.coffee', '**/*.js']
                            dest: ''
                        }
                    ]
                    insertGlobals: true

I found this issue: browserify/browserify#429 Not sure if it's helpful.

If you need more info let me know.

Just upgraded to 1.1 and browserify-shim 2.0.4 and I have a regression.
I am shimming JQuery and this code:

; browserify_shim__define__module__export__(typeof $ != "undefined" ? $ : window.$);

}).call(global, undefined, undefined, function defineExport(ex) { module.exports = ex; });

causes this error: Uncaught ReferenceError: global is not defined

My grunt task looks like this:

browserify:
  'www/module.js': ['src/coffee/*.coffee']
  options:
    noParse: ['jquery']
    debug: true
    transform: ['coffeeify']
    ig: true
    shim:
      jquery:
        path: './components/jquery/jquery.js'
        exports: '$'

Anything I am missing or a regression?

When I have the following configuration...

browserify: {
    sync: {
        options: {
            shim: {
                jwplayer: {
                    path: 'assets/scripts/vendor/jwplayer/jwplayer.js',
                    exports: 'jwplayer'
                },
                jquery: {
                    path: 'assets/scripts/vendor/jquery.js',
                    exports: '$'
                },
                'jquery.links': {
                    path: 'assets/scripts/vendor/jquery.links.js',
                    exports: null,
                    depends: {
                        jquery: '$'
                    }
                },
                visibility: {
                    path: 'assets/scripts/vendor/visibility.js',
                    exports: 'Visibility'
                }
            }
        },
        files: {
            'assets/compiled/scripts.js': ['assets/scripts/sync.js'],
            'assets/compiled/test.js': ['assets/scripts/test.js']
        }
    }
},

The first file, /compiled/scripts.js works as expected, while the latter file /compiled/test.js gives me the following error when I try to use it:

Uncaught TypeError: Cannot set property 'exports' of undefined 

For the sake of testing, both source files have identical contents:

/*
Tandem Module
Includes and initializes all Tandem.io modules
*/

var _ = require('lodash');
var Backbone = require('backbone');
var $ = require('jquery');

// set up namespace
window.tandem = window.tandem || {};

var chat = require('./chat');
var playlist = require('./playlist');
var player = require('./player');
var users = require('./users');
var Title = require('./title');
var Connection = require('./connection.js');
// transmit events across modules
var mediator = _.extend( {}, Backbone.Events );

$(function(){
    if( $('#chat').length ) chat( '#chat', mediator );
    if( $('#playlist').length ) playlist( '#playlist', mediator );
    if( $('#player').length ) player( '#player', mediator );
    if( $('#users').length ) users( '#users', mediator );
    if( $('body#page-room').length ){
        tandem.title = new Title( mediator );
        tandem.connection = new Connection;
    }
});

I keep getting an error message saying Warning: path must be a string when I try to run the browserify task in my grunt config. Following your documentation and random examples I found in the issues on this repo... I've tried both this:

    browserify: {
      'public/assets/scripts/app.js': {
        src: 'public/app/main.js'
      }
    },

and this:

    browserify: {
      src: ['public/app/**/*.js'],
      dest: 'public/assets/scripts/app.js'
    },

and both of them throw the same error. Am I doing something wrong here?

When running grunt task using grunt 4 this error is thrown:

Warning: Object #<Object> has no method 'expandFiles' Use --force to continue.

please see: gruntjs/grunt#633

I'm not sure why, but I keep getting this error when I try to compile a fairly simple script:

Running "browserify:hh" (browserify) task
>> Bundled handlebars_helper.js

Running "browserify:test" (browserify) task
Warning: Cannot find module './lib-cov/mocha' Use --force to continue.

My configuration is like so:

grunt.initConfig({
    browserify: {
        hh: {
            files: {
                'handlebars_helper.js': ['src/browser.js']
            }
        },
        test: {
            files: {
                'test/assets/test.js': ['test/index.js']
            }
        }
    }
});

And the file I'm trying to compile (test/index.js)

var assert = require('assert');
var mocha = require('mocha');
var Handlebars = require('handlebars');
var handlebars_helper = require('../index.js');

describe( 'Handlebars Helper', function(){

    handlebars_helper.help( Handlebars );

    it( 'registers helpers', function(){
        assert( !!Handlebars.helpers.replace, 'replace helper is registered' );
    });

});

Removing mocha makes the problem go away, but I've got no idea why it's trying to look in ./lib-cov/

With the browserify command you can do something like:

browserify -r underscore -r handlebars -o common.js

This would imply this config:

browserify: {
  common: {
    dest: 'common.js',
    options: {
      externalize: ['node_modules/underscore', 'node_modules/handlebars']
    }
  }
}

I would use this together with the external parameter of another task where you exclude these "external" libraries.

But it is currently not possible to skip the src parameter.

Do you think it is useful to enable this?

The order of files included in the Browserify bundle is nondeterministic, which means that tests can randomly fail. The tests need to be rewritten to be more precise than just comparing outputted strings.

Hey,

Love the plugin. I have hacked together cached compiling based on the code in https://github.com/substack/watchify, so that when combined with grunt-contrib-watch subsequent rebundlings are almost instantaneous.

Should I clean it up and submit a pull request?

Thanks,
Phil

Hi,

I would like to be able to register multiple tasks so that grunt browserify:foo and grunt browserify:bar would run different tasks.

Examples:

browserify: {
  dist: {
    'app.js': { <options> }
  },
  test: {
    'tests.js': { <options> }
  }
}

Creates either app.js and tests.js or dist/app.js and test/tests.js

From my understanding of https://github.com/cowboy/grunt/blob/master/docs/api.md#gruntregistermultitask that's the way many other tasks work.

I'm using grunt-browserify with grunt 0.4 and this code snippet

browserify:
  'dist/js/application.js': ['compiled/**/*.js']

Running the command throws this error:
Warning: Cannot read property 'src' of undefined Use --force to continue.

Anyone seen this?

component-amd converts AMD modules to CommonJS. It would be pretty cool to have have this built in.

Browserify no longer supports passing aliases in the require map, see browserify/browserify#161.

It is also not possible to set aliases in the hook as "... need to do all aliases BEFORE you do the addEntry...".

We'll need to pass alias as an option.

If on the aliasMappings example you add a file under the shared folder that no file is requiring and that requires a non existing file:

require("lib/fake")

then you won't be able to browserify the example.
I could make the example work again by doing:

aliasMappings: [
{
cwd: 'shared',
src: ['/models/testModel.js', '/controllers/testController.js'],
dest: 'lib',
},
]

So basically it will be great if it wouldn't try to parse files that are not on the require tree.
Doest that makes sense?
Thanks

http://gruntjs.com/configuring-tasks#older-formats
The current format (including the example usage in README) follow the old one that's deprecated.

When using alias or aliasMappings with debug set to true, the source map does not correctly dereference the module.exports alias.

For example, when I try to view the source file for an aliased file, I see something similar to this:

module.exports=require('4cfN1i');

I've confirmed that when using browserify 2.33 from the command line, the source map references the source file as expected. Let me know if you need me to provide anything else. Thanks! I truly appreciate your hard work on this task!

At browserify 2.33.* exist key --extensions. I use it with reactify and .jsx files. It will be good to have it in this grunt plugin.

Actually i add it, but i stucked with tests, because browserify in tests delegate require to node require and it does not see custom extensions.

Thanks.

This might be a bit outlandish, but I'd like to be able to configure the browserify task in the same way require.js can be: with the require.config method, before require is called. Ideally I'd be able to pass a configuration object not unlike that used in the gruntfile, which would be mixed in with anything already set. This allows developers to add shims without having to dive into Gruntfile.js.

Hey! Thanks for taking over this plugin. I had a PR I never finished readied for it: https://github.com/shama/grunt-browserify/blob/master/tasks/browserify.js

It uses the Grunt recommended this.files API over accessing the config through this.data (we actually intended on removing the this.data API but didn't get to it before releasing v0.4). It also incases options into options and uses this.options() to make it more future proof.

This would fix #24 and allow this plugin to be configured with all the Grunt supported ways.

I just wanted to know if you'd be okay with a PR for these things. Let me know and I'll rebase with the latest then send a PR over. Thanks!

Optional argument function which takes the filename as an argument and returns the desired alias.

I'm trying to include this package in my project: https://npmjs.org/package/jquery-browserify. He says that you can re-map it to the name jquery so that you can require("jquery") using the following configuration code:

browserify({
  require : { jquery : 'jquery-browserify' }
});

I'm no browserify expert, but this does not work for me:

browserify: {
  app: {
    options: {
      require: { jquery: 'jquery-browserify'}
    },
    src: ['public/app/app.js'],
    dest: 'public/index.js'
  }
},

Is there an obvious solution to this that I am missing, or do you need to manually add support for that setting?

Can I ask, respectfully, about these lines:

if (aliasDest && /\//.test(aliasDest)) {            
   aliasDest = path.resolve(aliasDest);
}

It seems to be pointless and defeats the purpose of the alias. If I happen to have a file that resolves to the alias, it publishes the alias at that path at not to what i set it it at. Consider this tree:

common/
  errors.js
  controls.js
app1/
  forms/
    form1.js
    form2.js
  widgets/
    widget1.js
app2/
   form1.js
    form2.js
  widgets/
    widget1.js
Gruntfile.js

Let's assume the purpose of the alias on errors.js and controls is to keep form1.js from having to reference ../../common/errors, so the alias is set to common/errors.
But since common/errors just happens to path.resolve relative to the Gruntfile, the alias is overwritten and the intrepid developer spends several hours trying to figure out where their aliases went.

But the statement itself seems questionable anyway. An alias is a proxy and a semantic-less construct. Why look for the file anyway? Several lines above, aliasSrc is resolved and that should be all that is needed. No?

You have a lot of unnecessary stuff listed as a dependency. As a result, npm install grunt-browserify installs a bunch of crap that end-users don't need:

dependencies {
  "grunt": "~0.4.0", // already in devDependencies, remove
  "browserify": "1.16.x",
  "grunt-contrib-jshint": "0.1.x", // should be moved to devDependencies
  "grunt-contrib-nodeunit": "0.1.x", // should be moved to devDependencies
  "grunt-lib-legacyhelpers": "0.1.x"
}

Thanks!

I've got a fork of grunt-watchify that implements grunt-browserify's current interface, mostly by copying the source of grunt-browserify. Maintaining both feels wasteful. I think merging the projects could benefit both.

With browserify/watchify#6, grunt-watchify is significantly faster than the current grunt-browserify when bundling multiple files from the same target that share many modules. It's doing #70, and the cache sharing code is handled by substack/watchify, so it doesn't need to be duplicated in this task.

goodeggs/grunt-watchify also gets nicer syntax errors when combined with coffeeify by grunt.log.erroring the errors. It still exits with an error code.

A merge could introduce one extra option, keepalive, for using browserify in endless watch mode when used without grunt-contrib-watchify.

Thoughts?

The transform option, which is very handy, is not currently mentioned in the docs.

I'm using grunt-browserify to bundle up a library. I then want to use this library in another project. I configure the grunt-browserify task for the library as follows,

browserify: {
    options : {
        transform: ['debowerify'],
        alias:
        [
            'scripts/Ascot.js:ascot.main',
            'scripts/DOMView.js:ascot.DOMView',
            'scripts/EventEmitter.js:ascot.EventEmitter',
            'scripts/Model.js:ascot.Model'
        ]
    },
    main: {
        src  : ['scripts/index.js'],
        dest : 'ascot.js',
        options : {
            standalone : 'scripts/index.js'
        }
    }

So the intention is to have a single file dependency that externalizes those aliases for use throughout my app. The index.js file is a single point-of-entry wrapper that does the following,

'use strict';

var ascot = require('ascot.main');
require('ascot.EventEmitter');
require('ascot.DOMView');
require('ascot.Model');

module.exports = ascot;

In my actual app, I am using debowerify to automatically alias my library. So the output from my library browserify step is at

bower_components/ascot/ascot.js

Which I reference in my app using,

require('ascot');

I have also configured debowerify in my app's gruntfile as follows:

browserify: {
    options : {
        transform : ['debowerify', 'hbsfy']
    },
    dist: {
        src  : ['<%= yeoman.app %>/scripts/main.js'],
        dest : '<%= yeoman.dist %>/scripts/index.js'
    },
    debug: {
        src     : ['<%= yeoman.app %>/scripts/main.js'],
        dest    : '<%= yeoman.app %>/scripts/index.js',
        options : {
            debug : true
        }
    }
}

This must successfully load my library file, but I then get an error when running the task:

Running "browserify:debug" (browserify) task
Warning: Cannot find module 'FFRxKb' Use --force to continue.
Error: Cannot find module 'FFRxKb'
    at /Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:45:17
    at process (/Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:111:43)
    at /Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:120:21
    at load (/Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:55:43)
    at /Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:61:22
    at /Users/ryanvangundy/Documents/MyProject/node_modules/grunt-browserify/node_modules/browserify/node_modules/browser-resolve/node_modules/resolve/lib/async.js:18:47
    at Object.oncomplete (fs.js:107:15)

It is not clear to me how it is intended to work currently, but on Windows the .gitignore content is not resolved to .npmignore. This makes node_modules and tmp show up in untracked files.

Would it be possible to move things to .gitignore and remove .npmignore?
npm uses .gitignore if .npmignore is missing.

I'm sorry if this has been asked or is already possible, but I feel the need to ask directly.

Anyway, I'm the author of grunt-react which has a browserify transformer that works very well. Except, if a compilation error is thrown or a require(...) call fails (e.g. File not found), then the entire grunt watch task fails.

To get around this, I'm using grunt-parallel (or grunt-concurrent) to spawn browserify separately & ignore errors, but was wondering if this were something that can be accomplished with the repo as-is.

Thanks!

It will be better if there is an outfile option within the target, so explicit task targeting will look like browserify:release instead of browserify:path/to/release.js

Pulling in @bclinkinbeard, @hurrymaplelad, and @shama.

It's time to talk about v2. I've been keeping this on the back burner for awhile, but I think I finally have bandwidth to work on it.

What needs to get done:

• a rewrite of the core task. It's a huge function with a bunch of if/elses. It needs to be broken down into a much more logical structure. I don't necessarily think we need to expose the functionality via module.exports and unit test it or anything, but cleanliness will definitely help with maintainability.
• Integrate watchify
• Normalize how paths are handled. Right now, it's a bit haphazard and definitely non-standard, mostly as a result of filepath logic being changed on the fly. I'd like to follow grunt-watchify's example here, and just normalize to path.resolve.
• One huge thing for me - changing how alias and external are handled. It's incredibly annoying to have to specify aliases for a common module, and specify the same aliases AGAIN as external for another module. I'd like to declare common module aliases as an array, and then re-use that array to pass to external of another g-b task. (If this doesn't make sense, I can put together a sample gist.)

What else?

I am using grunt-browserify in a context with no access to require(). Normally, I would supply -r to browserify to expose a global require function, but I can't see how this is possible with grunt-browserify.