I like ES modules. ProseMirror was originally written using ES modules, but downgraded to CommonJS at some point because the compilation step slowed down my development process too much (I really dislike waiting for recompilation or accidentally refreshing before the build is done, and even with incremental builds, the build times were noticeable). It seems both Firefox and Chrome have started rolling out ES module support behind a flag. So that would make make them an attractive format during development again.
I’ll do some experiments soon. Would the src/ directory (not dist/) moving back to ES modules cause anyone inconvenience? Relatedly, would having a single dist/index.js instead of different dist/* modules, with that index.js being created by rollup, be an issue for anyone?
Sounds good to me! I don’t think that ES modules and a single dist/index.js would cause any inconveniences/problems for my workflow with ProseMirror Especially now that Firefox and Chrome seem to have started rolling out ES module support (but I haven’t tried it yet).
@marijn What were you using for the compilation step before?
I ask because I’ve been using JSPM with my Knowledge Base Web app Clibu for quite some time and don’t find app startup time an issue during development. And of course at release, all code is compiled into a bundle.
AFAIC ES6 modules are the only way to go for any complex JS app.
Well, it seems I didn’t think this through all that well – even if you have browser support for ES6 module syntax, it seems you still can’t run a serious modular library directly in the browser, since it won’t resolve modules – i.e. if you say import {foo} from "prosemirror-model", it won’t have Node’s cleverness for finding the module prosemirror-model.
I haven’t found a way around this yet. Maybe testing browser JS without an intermediate compilation step is just not something anybody cares about anymore.
Given this new insight, I’m somewhat on the fence about whether to release 1.0 with CommonJS or ES module-style. Does anyone have a strong opinion either way?
The issue is that the browser will not know the right url for the modules. If you use urls that start with ‘./’ there is no problem.
In WebODF we use custom module loading code. It has a tiny compile step that creates a json file that maps the short import, e.g. ‘prosemirror-model’ to the full url. This json only needs to be updated when a module is added, moved or deleted. Most of the time, you can use reload without this step.
I’ve found that using typescript middleware in nodejs that does dynamic recompilation to be so fast that it’s rebuilt by the time I’ve switched between text editor and browser. I imagine that the npm module babel-middleware is similarly fast.
As of today, the src/ directory in the prosemirror-* modules is written using ES modules, and the code in dist/ is compiled by rollup, one file per module. If you were requiring submodules (prosemirror-something/dist/something.js) directly, that will stop working, but you shouldn’t be doing that anyway.
I had some (largely unrelated) trouble getting NPM5 to behave with the inter-linked checkouts development setup, so I’ve moved to yarn for the dev setup (but you don’t need to worry about that unless you’re using the pm helper script).
Especially now that Firefox and Chrome seem to have started rolling out ES module support (but I haven’t tried it yet).