use direct es6 import in dev mode if available

[bubbatls]

Allow better performances for dev, avoiding to babelize file on browsers which do not need it. the "pathToRoot" config must be set if es6.js is not at the root but redefined in requirejs config like paths: { "es6":"lib/requirejs/es6", } then in es6 config you will need to put es6: { pathToRoot:'../../'
}

For huge es6 file, the loading time is really better on Chrome. For firefox it fallbacks to the past code, and I didn't test other browsers, because it is for dev only

[prantlf]

This is an interesting idea, but it will not work in general.

This would work only if you use only JavaScript imports. As soon as you start using RequireJS plugins like css or hbs, you will not be able to import the source directly; you will have to depend on the RequireJS plugins triggered by the define function. Another problem will be if you use JavaScript imports on paths configured in the RequireJS configuration and not just the paths starting with baseURL and relative paths.

[bubbatls]

For those points I use a service worker that rewrite my ressources to es6 module.

[prantlf]

I see, an inspiring approach. It could solve the performance problem that I am afraid of, once I introduce the babelification plugin. (I am actually going to use requirejs-babel7 as the es6 plugin.) The code base that I am going to modernise contains more than two thousand modules and loading all of them takes time on a development page.

We use RequireJS to the fullest. Pseudo modules module and require, and plugins, which not only generate JS from text, but also the plugins, which include code executed during the runtime, like i18n and some home-grown extensibility plugins. And the RequireJS bundles. Now I perform the conversion ESM->AMD for both optimiser and the browser mode, which allows me reusing the RequireJS and r.js infrastructure. (I am using a modified r.js with fixed source map handling.) I am not sure if I am ready for the effort of bridging the plugins in the service worker.

If I get too bad performance, I have other "plan B" - instead of using Babel, employing a hand-written ESM->AMD converter focusing only on imports/exports using a parser and code generator like acorn and astring.

[bubbatls]

In my mind, as es6 works on all major browsers the es6 plugin should not have to exists anymore. requirejs should take es6 directly. And the use of babel should be only for building the prod version, and so no need to babelize module per module in dev but only the final js files. For the plugin beeing usable easyly in dev, I think that your plan B is really better. But it is funny, because two weeks ago I plugged the reverse of your idea in my service worker. It now does AMD->ESM convertion

[prantlf]

Let me give more detail about the problem that I face. Pure AMD modules would work well, converted to ESM and loaded by the import statement. However, there are RequireJS plugins, which do not only produce a JavaScript module, but run some code during the runtime. For example:

define(['plugin!some/module/path', ...], function (x) {
})

This cannot be just translated to, because the import statement is configurable, but not pluggable:

import x from 'plugin!some/module/path'

It would have to be translated to:

import x from 'some/module/path.extension.js'

Where the some/module/path.extension.js would be needed to be built in the service worker using the logic of the RequireJS plugin. Doable, but not my first choice...