I’ve started looking at supporting custom Web components into the ProseMirror editor. These days, I develop in Typescript for Chrome and Firefox which support ES6 modules.
I have locally update the package.json files of different modules to introduce a definition module similar to main, except that it points on the file in src/ instead of dist/. It works well up to trying to process an mport * as OrderedMap from 'orderedmap'… This import fails because the index.js is not an ES6 module (it’s just a compiled CommonJS version I guess).
Is it possible you have the ES6 version of it? I can refactor the code otherwise.
None of the ProseMirror packages are ES6 modules, are they? All their package.json files point to a CommonJS file in dist/.
There’s a good reason for this: there is no consensus on how ES6 packages are to be distributed. There’s some informal ideas like the "module" field, but that is way too underspecified to get us anywhere.
So as long as that is what the situation is like, ProseMirror and its dependencies are distributed as CommonJS packages, since I don’t want to chase contentious, unstable package formats.
I don’t ask you to replace the CommonJS package format, I just ask to offer the ES6 format of the OrderedMap dependency. Small addition to make the use of ProseMirror even more flexible
I’m fine with the CommonJS format. It’s just that I prefer dealing with ES6 code (Typescript code in fact) wherever I can, while letting the conversion/packaging/tree shaking for the last stage…
Most of the ProseMirror code, with the addition of module="src/...", can be processed by my NodeJS server (offering dynamic rewriting of bare bone imports) and are natively accepted as ES6 modules by Chrome, Safari, and Firefox (just waiting the next Edge to use Bing). I know that module is not part of the npm standard, but many tools like rollup and webpack use it.
I know, I’m just saying that I’m holding off making ES6 modules part of my distribution format until there’s a clear spec on how that can be done.
For now, not having a build step at all in tiny modules like OrderedMap is convenient, and if you’re setting up an oddball build/serve system that needs ES6 modules, I guess you can also run some code transformation that creates ES6 from CommonJS.
If you want to do this in production you should probably generate your own ES module builds, but for rapid prototyping it’s quite convenient to be able to use his directly from unpkg in bare module-type script tags with no transpiler or build step.
I thought @jimpick had just added the module field and left everything else as is was, right? In that case it would seem that the packages should work for all kinds of usecases, not just for using unpkg.
