Code modularity¶

Some information on this page is outdated, as indicated inline.

Complex functionality has to be split into multiple javascript files. However, managing these by hand can get very cumbersome as project grows. There exist various ways of bundling javascript. Some tools commonly used for this purpose are Browserify, jspm, Webpack, RequireJS and Babel. Yet another option is to use javascript modules - a native feature of the language.

• Table of contents
• Code modularity
  • Native modules considerations
  • Bundler considerations
  • Current approach

Native modules considerations¶

Javascript modules are rather convenient to use. Unfortunately, support varies between browsers and in some cases there is simply no facility to load a module. An example of such case are content scripts. They are loaded as listed from manifest.json file and need to be traditional script files. Chromium already offers a way to load a module dynamically from within a traditional script, but all modules loaded this way (including those pulled by the initial one) need to be listed as web-accessible resources in the manifest.

Bundler considerations¶

If we decided to use a bundler, it would create an additional dependency for the project. Hachette clearly has no need for many of the features bundlers provide and as long as the functionality needed from them can be provided by a simple script, this is preferred.

It is also worth mentioning some of the bundlers are part of the Node.js/NPM ecosystem which, although consisting mostly of libre software, is problematic from software freedom point of view due to requiring people to rely on a third-party package manager and a non FSDG-compliant software repository. If any bundler is to be used, it is preferred to choose one that doesn't rely on Node.js or at least is packaged for an FSDG-compliant GNU/Linux distribution.

Current approach¶

At some point early on, this extension utilized native javascript modules. Due to problems with these, sources were slightly modified, so that the import/export semantics of modules were mostly retained, but import and export statements were replaced with assignments and accesses to keys of the window object. Each script file's contents are wrapped into a function call so as not to clobber the global namespace. Properly ordered lists of scripts to load in each context were compiled by hand and placed in manifest.json and relevant HTML files.

In the near future hand-compiled lists are going to be replaced by ones automatically generated using a script (bash is being considered for this task) and accesses to window object by import and export statements of some simple, yet-to-be-decided syntax, possibly enclosed in JavaScript comments. By then we will also stop using the window object directly and will instead be creating and using another object under window to store the exports. (This has already occurred; documentation needs to be updated.)