Porting from RequireJS to ES6

Background

We’ve a modest (6-figure SLOC) dimension codebase for net purposes that has traditionally been constructed on RequireJS.

https://requirejs.org/

If you have not used RequireJS earlier than, know that it is really a fairly neat answer. Notably in early-to-mid 2010s, there have been no constant cross-context module loader environments. (Keep in mind the YUI library?) You had been both packing your JS supply (nonetheless piecemeal even with one thing like Browserify), in all probability from a highly-dynamic and inconsistent CommonJS/Node context, or writing immediately inside <script> tags themselves (my abdomen feels sick…), if you did not have an honest loader to make use of.

In comparison with getting Node-style CommonJS modules to work inside a browser context, RequireJS may actually really feel like a breath of contemporary air. Builders merely used CommonJS-like require() statements however may outline modules inside a self-contained closure with some expectation of constant meta symbols (module, exports, and the require perform itself). The loader extensions had been significantly distinctive and helpful, supplying you with a approach to hook in all kinds of various assets. I even had a .ZIP filesystem loader for archiving/compressing and exposing static property!

RequireJS used a distinct loader normal, known as AMD (for “asynchronous module definition”). By defining and loading modules asynchronously, you possibly can anticipate higher startup efficiency when your web page or app loaded (versus loading one huge bundle of JS, which was troublesome if not not possible to debug in manufacturing with no heavy solid of developer instrument plugins–if they existed in any respect). It was nice to make use of a browser-first context with specific symbols (you would be shocked how a lot Node implements implicitly), and porting different assets from CommonJS was surprisingly straightforward since you possibly can all the time simply wrap a definition in an AMD-compatible closure. This remained the case even when UMD (common module definition) headers had their time within the solar for just a few years.

ES6 launched help for import and export symbols, syntax, and habits. Surprisingly (largely I feel due to the robust buy-in into CommonJS/Node environments), it took a very long time for ES6 modules to take off. Even for the previous few years, main packages targeted largely on (say) cross-building to an ES6 module, however many tasks have since efficiently migrated the underlying codebase to ES6 with builds “out” to different contexts.

There are nonetheless a big number of causes to retain different module environments, largely (in my expertise) due to different abstraction buy-ins that obfuscate how code is loaded and utilized inside the browser context on deployment. React (basically) and .TSX (particularly) are nice examples, due to how strongly parts are mapped to file buildings and with the requirement to carry out an up-front construct go anyway. And who can overlook JQuery? Ha ha ha, simply kidding.

Motivation

This brings us to our official migration. Farewell, RequireJS! You could have served us nicely.

(A facet observe: Generally you will note ES6 modules known as “ESM”. Additionally, you will see a file extension .MJS used, largely to inform Node that it’s utilizing a JavaScript module. From the consumer’s perspective, sort="module" is enough, however it may be good to make it apparent, and well-liked editors like VS Code find out about .MJS already. The largest adjustment you would possibly want is including the MIME sort mapping to your static file server, which is fairly straightforward to do in one thing like nginx.)

There are a number of main causes for this migration:

1. RequireJS has reached EOL (finish of life) and is not receiving main updates. In one thing as basic as a module loader, stability is an effective factor, however on this case it’s dropping help total inside the ecosystem as ES6 modules lastly attain a stage of important mass.

   https://github.com/requirejs/requirejs/issues/1816

2. RequireJS has had, by design, important efficiency points on module loading. ES6 modules implement import and export symbols and logic inside the JavaScript interpreter specification itself, which suggests a lot better efficiency for module loading basically. That is along with not string-parsing each module load for require() statements. Look it up, it is true! When loading a outline-enclosed module, RequireJS will flip it right into a string and match towards a sample for require() calls to resolve inner dependencies. For a loader system whose main advantages are supposed to incorporate asynchronous efficiency, this was really type of mind-boggling once I discovered about it. Amongst different issues, this implies you’ll be able to’t dynamically “assemble” require() arguments to resolve dependencies at runtime.

   https://github.com/requirejs/requirejs/blob/898ff9e60eb6897500720151c0b488b8749fbe8d/require.js#L2086

3. ES6 modules are natively cross-compatible throughout each browser and command-line (e.g., Node and NPM/Yarn) contexts. This implies it turns into MUCH simpler to function out CI integration on the module stage for any dependency that might profit from it, together with obfuscation/minification; testing; documentation; deployment/launch triggers & bulletins; and plenty of different nice features–even although the module itself is written to be browser-first.

   

4. I discussed the neighborhood at massive has lastly reached important mass in its migration in the direction of ES6 modules (away from browser-native, RequireJS, Node/CommonJS, and another UMD-header contexts). This implies reusability (for each our personal internally-developed modules and for another dependencies we need to leverage) is MUCH higher and simpler. No extra random headers! No extra arbitrary closures to implement a cross-compatible context! It is fairly thrilling, the extra you consider it. Most open supply JS tasks are on the level the place they’ve native help for ES6-compatible builds, so it is merely a matter of import image from "path"; and also you’re good to go. That is significantly true if, like us, you’re utilizing git submodules as a substitute for package deal administration, particularly since you’ll be able to construct and pull an ES6 module from (say) a dist/ folder for any tasks that are not already ported.

   https://www.zachgollwitzer.com/posts/scripts-commonjs-umd-amd-es6-modules

5. Talking of paths, import has a number of modes through which it may be used with respect to how module paths are resolved. (There’s additionally somewhat-experimental help in main browsers for an importmap characteristic to outline how module paths are resolved, however we have not touched that but.) The trail decision for RequireJS wasn’t significantly unhealthy as a result of it was all the time based mostly on the host path in any case (being evaluated within the browser context), however on the shell facet (for CI and so on.) this can be a good enchancment for consistency’s sake, particularly to get away from node_modules/ hell.

Porting

So, you’ve a big assortment of RequireJS modules. The way to you port them? I discover there are three main modifications wanted to most modules:

• First, you’ll want to get rid of the “outline()” closure and any dependencies on the symbols it exposes (module, exports, and so on.).

BEFORE:

outline(perform(require, exports, module) {
    class MyClass {
        ...
    }
});

AFTER:

class MyClass {
    ...
}

• Subsequent, you’ll want to exchange “require()” statements themselves with acceptable “import” statements.

BEFORE:

const dependency = require("path/to/dependency");

AFTER:

import dependency from "path/to/dependency.mjs";

• Then, you’ll want to change your export statements (there have been 3 ways to export symbols in RequireJS closures: coming back from the closure, assigning to exports, and assigning to module.exports).

BEFORE:

return Object.assign(MyClass, {
    "__metadata__": "..."
});

AFTER:

export default Object.assign(MyClass, {
    "__metadata__:" "..."
});

Lastly, there are doubtless some modules that make the most of exterior assets. For instance, a few of our modules reference a side-loaded .CSV desk for which we had a customized RequireJS module loader. The loader extension, when require() arguments started with the registered prefix “csv!”, would use Papaparse to remodel the content material right into a module-level Array of Objects implicitly. This will simply get replaced by inline chains of fetch() after which() Guarantees, utilizing the await key phrase. (By the way, this frees us from a further dependency, as a result of we not want the “loader” module to outline the extension, in addition to releasing us from the sticky global-context registration of the extension towards the prefix.)

BEFORE:

require.config({ "paths": {
    "csv": "mycsvloader"
}});
const information = require("csv!path/to/desk.csv");

AFTER:

const information = await fetch("path/to/desk.csv")
    .then(response => response.textual content())
    .then(textual content => papaparse.parse(textual content.trim(), {
        "header": true
    }).information);

This finally ends up being enough for 99% of instances I’ve come throughout.

Conclusion

I’ll admit that I nonetheless have sentimental worth for RequireJS. For years, it allow us to “short-circuit” the module wars and focus explicitly on sturdy improvement of reusable front-end-first modules. However, as soon as we had the effort and time to port to ES6 modules, the advantages had been clear and we’re already seeing important enhancements. Specifically, I’ve to say I am very excited for the way a lot CI energy we are able to convey to bear on particular person modules themselves.

In the event you’re in an analogous place, I might encourage you to contemplate investing the effort and time to conduct an analogous refactor. The JavaScript ecosystem is nothing if not extremely hyper-pluralistic–but for one thing as basic as module loading, it is good that we lastly appear to be converging on one thing that might be secure nicely into the long run (particularly on the interpreter stage, as an alternative of being a part of one more higher-level framework). I feel in the long term that is really going to allow a lot extra range and pluralism within the JavaScript ecosystem because the world of builders begins to collectively leverage a a lot higher diploma of reusability and cross-compatibility.