Le mardi 27 septembre 2016 14:49:36 UTC+2, David Teller a écrit :
> I have opened bug 1305669 with one possible strategy for migrating
> towards RequireJS.
RequireJS [1] is a peculiar choice for chrome code especially if your goal is
static analysis.
From this thread and what I read in bug, it doesn't seem you want require.js.
I'll take a minute to try to setup some vocabulary. There are currently mostly
3 module formats in use in the front-end development.
* Aynchronous Module Definition (AMD) which first/main loader implementation is
require.js [1]. Its motivation was mostly to provide a way to load modules
asynchronously in front-end code. Example of how it looks:
* CommonJS (which Node.js is the main user right now, but front-end can use
this syntax via tools like browserify and webpack). This form of module imports
modules via the syntax 'var x = require('x')'
* ES6 modules which defines both the static syntax ('import' and 'export'
keywords) and the (dynamic) module loader [2]. The latter is not ready yet but
is getting there.
From what I've read, it looks like you want to transition to CommonJS, not AMD.
If you want a CommonJS loader, be aware that there is already one at
https://hg.mozilla.org/mozilla-central/file/66a77b9bfe5d/devtools/shared/Loader.jsm
On the topic of transitioning, I don't maintain the Firefox codebase, so feel
free to ignore anything I say below.
But for one-time top-level imports, the ES6 syntax seems like a better bet
given from what I've read that they're supported in chrome and are the end-game.
As far as dynamic/conditional imports, there doesn't seem to be much value to
move from Cu.import() to require() given it's unlikely static analysis tools
will do anything with either anyway (I'm interested in being proven wrong here
though) and the standard module loader [2] will beg for another rewrite
eventually.
hope that helps,
David
[1] http://requirejs.org/
[2] https://whatwg.github.io/loader/ &
https://github.com/whatwg/loader/pull/152/files
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
