Migrate to ES6 modules and build with WebPack
gruns opened this issue · comments
WebPack isn't a good fit to build the current version of IWC because the current
version of IWC isn't divided into composable modules. Instead, every file
src/sj.js
src/utils/BasicUtils.js
src/utils/Error.js
src/utils/Array.js
src/utils/Object.js
src/utils/Observable.js
src/utils/LocalStorage.js
src/iwc/iwc.js
src/iwc/InterlockedCall.js
src/iwc/SharedData.js
src/iwc/EventBus.js
src/iwc/WindowMonitor.js
src/iwc/Lock.js
src/iwc/Client.js
src/iwc/Server.js
modifies the global SJ variable and would need to be shimmed:
The correct, modern approach is to update IWC's components to composable
ES6/ES2015 modules. IWC could then be published to npm, installed with npm,
and cleanly bundled and used like
import { iwc } from iwc@slimjack: Is an overhaul of IWC to ES6 modules acceptable? That's the correct,
big picture solution instead of a single, implicit global variable SJ.
If so, I'll also modernize IWC to ES6 modules along with the migration to
WebPack.
@gruns What about IE support?
IE, unfortunately, doesn't support ES6 modules.
One pragmatic solution is to build two script versions:
IWC.es6.jsIWC.global.js
The former is an ES6 module and exports IWC. The latter defines window.IWC
globally for use in IE (and other poop browsers).
For a concrete example of this approach, see
Notably this line
which contains the series of simple sed commands that modifies
IWC.es6.js into IWC.global.js.
Is this approach, with one ES6 JS file and one global JS file, acceptable?
@gruns Yes, it is OK for me to have two versions. Thank you.