Require.js Library Skeleton | Hacker News Reader

Require.js Library Skeleton

github.com

32 pointssahat10 comments

I believe this is actually promoting an anti-pattern, and will result in code that is hard to test and which isn't expressly modular.

From the source[1]:

* core.js creates the "myLib" object

* module1.js & module2.js augment "myLib" with additional properties

* myLib.js takes the final, augmented object, and assigns it to a global variable

There are many problems with this setup, but the main one is going to be that the module1.js/module2.js both alter the module defined by core.js. The augmentation is permanent (until page reload).

So, what you end up with is a situation where you cannot include module1/module2 without first including core; this is not modular code and will make testing those modules more challenging and brittle -- you effectively can't test them independently. Rather, you'd have to test the relevant properties on the myLib object or stub-out myLib with a mock.

When working with modules, you typically don't want to build up some giant, monolithic object -- rather, you should be pulling in modules as you need and using them independently. Each module should return it's own object, which you can freely use within the context of another module but which has no adverse side-effects on any other modules.

1. https://github.com/sahat/requirejs-library/tree/master/src

Your point is very important. The key to requirejs is to insist that all code after requirejs is on the page will have absolutely no manual work to handle dependencies. To do this, you need to not use globals, and instead get clever about making your code more modular. Think of the requirejs cache as a dependency injection mechanism (or a bunch of global variables that also are smart enough to initialize each other) and do all of your work through it.

If you want to 'augment' an object like this, consider instead exporting files like 'object-small' (which just depends on the object) or 'object-with-fancy-decoration' (which depends on the object and decorator and returns the decorated object). This way require can handle load order for you.

Also, the use of absolute paths (like "./core") is, in my experience, an anti-pattern with require. By using naked paths (like 'core'), you can move files around (between baseDir and some other path specified in your require config) without things that depend on them having to know that they have moved.

The main file is exporting a global variable (window.mylib) directly, when it should assume require.js is present and export itself as a module. Only when creating a stand-alone/static build for non-requirejs environments it should export a global. CommonJS support could be added too.

Entirely earnest question -- wouldn't it be disadvantageous to create a library using Require.js? AFAIK you can't compile out the Require.js dependency. Even Almond.js leaves this cruft. Shouldn't you design consumable libraries to be entirely clear of runtime dependency mapping/loading?

As a part of my workflow, libraries are built at compile time by a Grunt task. These modules are concatenated based on an externally specified dependency graph. The end result is no Require.js in the final production code.

I'm kind of against R.js as it adds complexity at runtime. Has anyone found a way around this? If it were compile time overhead alone, I wouldn't be so opposed.

I would recommend following the patterns outlined here: https://github.com/umdjs/umd

Nice work sahat. We are using this as the basis for our refactor of js portion of the bokeh plotting library at Continuum.

We built Close.io off of RequireJS and Backbone.js using a modified version of this: https://github.com/backbone-boilerplate/backbone-boilerplate...

have you thought about making this a yo generator?

what's a yo generator?

It's for creating a scaffolding project with yeoman: http://yeoman.io/generators.html

Reply on news.ycombinator.com