Add support for unnamed modules

[prantlf]

If you want to process the modules by the RequireJS optimizer (r.j) and let it assign the module names, you can configure this formatter to produce unnamed modules. Attempts to fix #1.

Command line:

AMDFORMATTER_NAMED_MODULES=false ./node_modules/.bin/compile-modules ...

Library:

var container = new Container({
  resolvers: [new FileResolver(['lib/'])],
  formatter: new AMDFormatter({ namedModules: false })
});

This PR is based on #7.

[eventualbuddha]

This is rather unexpected. Why are you using this instead of something like rollup or webpack?

[prantlf]

@eventualbuddha, if you have large product, which involves infrastructure for building and loading of a dozens of independently installable product components, which all consist of more then two thousand of RequireJS modules, rewriting the modularisation will be questioned a lot by the management. Especially when the the product parts are loaded dynamically depending on the RequireJS bundles feature, which is not available in ESM and would have to be added to some pluggable module loader like System.js.

The investment to a new module loading and bundling will not be small and while waiting for the right time to plan it, it is a pity to continue writing code using AMD.JS. Additionally, some newer parts of the product (UI library) can be bundled by rollup for modern products and would benefit from writing the new sources as ES modules. But the old product could be allowed to bundle the same sources too for the easiest integration.

The idea how to modernise source module coding, while being able to postpone modernisation of bundling:

• ES modules -> rollup -> modern ESM bundling
• ES modules, AMD.JS modules -> es6-module-transpiler & es6-module-transpiler-amd-formatter -> r.js -> AMD.JS bundling

Of course, that such "dually bundlable" ES modules would have to be limited to avoid the compatibility problems between AMD.JS and ESM. It appears, that all we would need would be exporting unnamed modules and restricting the default export to be the only export in the module and be placed as the last statement.

I replied only about the unnamed modules here, because there was some interest about it. Enforcing the default export rule is quite specific to the use case of sharing the same sources for two bundlers and I would not expect it to be accepted as a feature for this project. The goal of this project is loading any ESM module in an AMD.JS environment, but you have to know that it was an ESM module to deal with the default wrapper object. The goal of my project is to combine ESM and AMD.JS modules in one AMD.JS projects and be able to exchange AMD.JS for ESM by refactoring anytime.

Actually, I did not expect that you would still be watching this project. It is nice after all those years, thank you! :-)

[eventualbuddha]

Thanks for the explanation. I understand having an older codebase with lots of inertia keeping it from being changed.

My sense is that, with unmaintained tooling like this, you're better off maintaining your own fork of it. Trying to loop in the original maintainers is admirable, but I don't think @caridy or I have any interest in maintaining the original es6-module-transpiler tool chains. (If he does, I'm sure he can correct me.) Having your own fork will speed you up and ensure it works for your needs.

I'll leave this and the others open for @caridy to decide about.

[caridy]

yeah, I agree with @eventualbuddha, forking seems like the right approach for you here to maintain your legacy pipeline running while you still can add new things to it.