Packaging AngularJs apps

Question

I am building Angular Apps, using 1.x and have been for some time now. I use Bower to install Angular and the various packages that go with it and some other bits and pieces like Shivs, JQuery, ChartJs etc etc. I love using Bower as it's nice and quick and keeps everything in a consistent place for me to reference. I use Grunt as well as my task-runner and so I'd also like to be able to automate this process for silky smooth development.

Now as my Angular knowledge has increased and the scale of the apps that I'm building are increasing, I'm finding myself including dozens of calls to files within the index.html and I really want to tidy all this up, ideally into a nice app.js making it all much more manageable, not only for myself but for anyone else coming in and working on these apps.

I've seen maaany tools like requirejs, browserify and commonjs to name but a few, which all provide the kind of functionality I'm after, but when reading various tutorials or watching conference talks on the process, they all seem to conflict with one another on which is the best. I know to some degree (as with all these competing technologies) it's personal preference, and I was leaning towards browserify, but apparently this removes bower from the flow and uses NPM instead. I'd like to stick with Bower if possible. I've really enjoyed using it.

Does anyone have any suggestions or best practices they can offer that might clear this up for me? Would a simple concat with grunt/gulp just be the way to go?

Any useful comments/answers would be much appreciated.

Many thanks.

Answer 1

Use ES6 Modules along with a module bundler (my recommendation would be Webpack).

As you have correctly identified RequireJS and commonjs evolved around different (and slightly conflicting) goals and are incompatible. ES6 modules is a standardized effort towards modular javascript that is already well supported by transpilers (eg. Babel).

This article provides a great introduction to this new feature:

Even though JavaScript never had built-in modules, the community has converged on a simple style of modules, which is supported by libraries in ES5 and earlier. This style has also been adopted by ES6:

• Each module is a piece of code that is executed once it is loaded.
• In that code, there may be declarations (variable declarations, function declarations, etc.).
  • By default, these declarations stay local to the module.
  • You can mark some of them as exports, then other modules can import them.
• A module can import things from other modules. It refers to those modules via module specifiers, strings that are either:
  • Relative paths ('../model/user'): these paths are interpreted relatively to the location of the importing module. The file extension .js can usually be omitted.
  • Absolute paths ('/lib/js/helpers'): point directly to the file of the module to be imported.
  • Names ('util'): What modules names refer to has to be configured. Modules are singletons. Even if a module is imported multiple times, only a single “instance” of it exists. This approach to modules avoids global variables, the only things that are global are module specifiers.

Example of use of Javascript modules in practice:

//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';
console.log(square(11)); // 121
console.log(diag(4, 3)); // 5