Node & Browserify Require/Export Issues

[Shane-Goodwin]

You asked to post any issues I come across so I wanted to share some problems I had when I first started while using Node and Browserify. I had to change the require code for 3 of the files to get it to work:

modules/stickitUtils.js:
"Backbone.Stickit is undefined"
To get it to work, I changed the commonjs implementation to:

var Backbone = require('backbone');
Backbone.Stickit = require('backbone.stickit');
factory(Backbone);

Backbone.Stickit did not add itself to Backbone like it was supposed to so I did it manually.

---

modules/NestedCell.js, modules/NestedModel.js:
"Backbone.NestedModel is undefined"
To get it to work, I changed the commonjs implementation to:

module.exports = factory(require('underscore'), require('backbone-nested'), require('./mixins/cellMixin'));

Backbone.NestedModel was not found on the Backbone variable like it should have been so simply requiring backbone-nested instead of backbone solved the issue.

---

These probably aren't the preferred ways to fix these issues, but they worked for me. Just wanted to make you aware of them.

[kentmw]

I just ran the yeoman generator that uses browserify and it bundles correctly and runs smoothly. I'm using node version 4.0.0 and npm version 2.14.2. Perhaps you have different versions that are breaking things. Do you mind sharing with me your versions?

[Shane-Goodwin]

I'm using node v6.3.1 and npm v3.10.3

I'm able to compile everything fine. The issue comes about in the browser - using the compiled js file, I get JavaScript errors until I make the changes I mentioned. I'm specifically testing in Chrome.

[kentmw]

Alright, I'm up to node v6.3.1 and npm v3.10.7. Deleted my test app, rebuilt it via yo torso, have it gulp watching and inspecting it in Chrome. No errors I can see. I wanted to see if there was anything wrong with NestedModel or Stickit so I put some console logs in the router.

    console.log(require('backbone').Stickit);
    console.log(Torso.NestedModel);

They show these objects just fine.

Did you build up the project with the yeoman generator? Could you copy your package json dependencies?

[kentmw]

I also updated the version of torso from the one out of the generator v0.6.9 to the most recent version v0.6.16 and I'm getting the same results

[Shane-Goodwin]

I did not use the yeoman generator. I already had started the project before adding backbone-torso.

Here's my package.json:

{
  "devDependencies": {
    "browserify-shim": "^3.8.12",
    "gulp": "^3.8.8",
    "laravel-elixir": "*",
    "laravel-elixir-hbsfy": "^1.0.0"
  },
  "dependencies": {
    "backbone": "^1.3.3",
    "backbone-torso": "^0.6.16",
    "handlebars-runtime": "^1.0.12",
    "jquery": "^3.1.0",
    "jquery-countdown": "^2.2.0",
    "underscore": "^1.8.3"
  },
  "browser": {
    "//": "Note: jquery-countdown path is temporary until library adds commonjs require syntax. At that time, this path can be removed so that it automatically references the /node_modules package",
    "jquery-countdown": "./resources/assets/js/node_modules/jquery-countdown"
  }
}

[kentmw]

Alright so good news and bad news.

Torso defines it's dependencies it needs to work, namely jQuery and Backbone and states explicit versions. Currently, Backbone is set to v1.2.3 and jQuery is set to 2.1.3.

Good news is, if you want things to work, just remove these explicit dependencies from your package.json and you'll still be able to require them directly e.g. require('backbone') and require('jquery'), as they are already defined in torso. This will solve the instance mismatch problems you were experiencing.

Bad news, you won't be able to alter the versions of jQuery or Backbone.

If you use different version than Torso uses, you may run into strange behavior as Backbone and jQuery both store internal state, even if sparingly, and depending on who is requiring Backbone or jQuery (Torso or the application) you may get different instances of these libraries.

We've thought about ways to make versions of these dependencies configurable including making them peer dependencies (which is now deprecated by npm). Because it hasn't been a problem yet, we also haven't found the range of versions of our two major dependencies that work with any given version of Torso which would be an important step in making them configurable.

For now, if you can't just rely on Torso's versions of jQuery and Backbone, you could see if you could shim/aliasify your desired versions into Torso. I'm not quite sure how you'd force Torso to look up a directory when it will most certainly bring it's own earlier versions.

[Shane-Goodwin]

Got it. Thanks. Even after updating my package.json with your suggestions and running "npm update" yesterday, I was still receiving the same error. So I tried deleting node_modules and re-running "npm update" to start fresh. That fixed it.

[kentmw]

Added #286, #287, #288 which will resolve this issue.