WebReflection
ES6 Modules
- ES6 Modules with Rollup/terser (in place of browserify/uglify-js);
add
moduletopackage.jsonand changemain - npm: Add recommended fields to
package.json
The source is the same as before except with use strict and the IIFE removed (given module context), indentation adjusted accordingly, and and of course the export altered.
Since you are contributing in various place, I'd like to tell you how all my repositories are, in terms of consistency, and how I want to keep it that way.
ESM
The entry point of any ESM module is esm/index.js and everything related to that module should stay inside the esm folder.
Every ESM import should be Web compatible unless it's not possible other ways. Example, import anything from './some/file' is not acceptable, import anything from './some/file.js' is.
If there is no syntax to do special things like CJS would do, then it's OK to let bundlers resolve that (i.e. import 'module' since there is no standard way yet to resolve external dependencies.
The entry point should be the module field of package.json.
CJS
The entry point of any CJS module is cjs/index.js and and everything related to that module should stay inside the cjs folder.
You can create out of the box CJS equivalent via ascjs and the command "ascjs esm cjs" saved as "cjs" script in the package.json.
The entry point should be the main field of package.json.
No interoperability
Nothing between CJS and ESM is shared, I terms of files, those are two pure, independent, different, module systems.
Web
The main entry point for the web, if any, is the index.js. It should have a min option that creates a min.js file, and that file should be the unkpg entry of the `package.json.
UMD
I don't believe in UMD. I publish modules that work either on the web as global exports, or as CJS or as ESM. UMD makes no sense these days, because UMD cannot deliver ESM and also it cannot deliver for other platforms different from NodeJS.
Yes, I publish modules compatible also with GJS, or JSC, or even Nashorn, I don't want over bloated fairy tales in my repositories, and I consider UMD one of those.
A single source of truth
Sometimes it's the index.js, copied over as cjs/index.js and esm/index.js plus the related export, and sometimes it's the esm/index.js made CJS via ascjs and bundled for Web as index.js.
In the first case, I usually write ES5 compatible syntax myself to avoid the need of transpilers or over bloated final output due transpilers. As example, query-result was 60 LOC and transpiled about 400 lines. I had to manually craft, chose, and pick modern features to keep it smaller and non breaking once transpiled, and I hate doing that ... so I often just write older code.
However, like in hyperHTML case, if I pay attention to obvious things that bloat the transpilation without any real-world improvement (usually quite the opposite, where everything goes slower on already slower browsers) I write relatively modern code but I avoid everything that involves Symbol.iterators such for/of and [...spread] or ...rest.
This also helps with performance, whenever it's cryptical.
Anyway, to close this chapter, whenever somebody would like to help with a PR, there should be only changes in such source of truth, and an environment easy enough to install via npm i and work with through npm run build.
Apologies for the long answer.
About this PR, please follow above convention. The esm/index.js feel should be the entry point for ESM, using exact same code the index.js has, and so should do the CJS.
You can remove the exporting bit at the end of index.js file, since once there are 3 ways to load it it's clear which part should do what (i.e. the CJS/ESM should just export a module while the browser should overwrite).
It might be interesting to figure out how to create these 3 distinct files so that maybe, an extra core.js file with the shared logic could be used to generate index.js, esm/index.js and cjs/index.js.
If you think it's too much, I'll try to have a go whenever I have time, but I'm surrounded by requests these days and I am a full time employee and I also have a life after that ( or trying to 😂 ) so thanks for your help or patience.
Thanks for the instructions on your repository conventions.
...nothing between CJS and ESM is shared...
I am really confused...If CJS is derived from ESM (via ascjs), how are they not shared? Rollup + plugins seems fine to convert to the other formats without bloat (though I know Babel may add bloat). What problems are you trying to avoid by insisting on the distinctness of each module system? While the named + default exports can be an issue, IIRC, Rollup, at least with plugins, allows a way around this issue...
... using exact same code the index.js has, and so should do the CJS
You mean they are not live-loading any common file, but they may be auto-derived from one? Otherwise, I really don't understand what you mean...
... It should have a min option that creates a min.js file
By "min option", would Rollup adding a minified browser build script file there be ok?
Ok, I think re: everything else...
By the way, as far as coding conventions, are you not inclined to use ESLint? Might help with the ES5 enforcement not to mention catching bugs for the rest of us who can make mistakes. :-)
I've updated this PR per my understanding of your instructions, but let me know what further needs fixing...
I didn't remove the lines at the end of index.js because it is currently derived from core.js (via Rollup). If you want me to add a Rollup plugin routine to strip out the code which is not relevant for the browser or CJS, let me know.
Btw, that block at the end is problematic in a different way now that there is no module.exports there causing the block to throw--the first block will now apply to the browser as well... I'd expect though that we not only want to avoid overwriting the native console for CJS, but also by default for ESM--unless expose a method that could do that overriding...
nothing between CJS and ESM is shared means that a file outside cjs or esm folder cannot be used in both modules systems. There is no require('../extra') and import from '../extra' 'cause the module system is different.
by insisting on the distinctness of each module system ...
Those are different modules system, I don't care about bundlers 'cause bundlers can work out what to import, standard ESM doesn't.
are you not inclined to use ESLint?
I don't care much.
Might help with the ES5 enforcement not to mention catching bugs
I have 100% code coverage to catch bugs, linter is less important for that.
for the rest of us who can make mistakes
if there are tests and test coverage, mistakes are easy to avoid.
I don't care about ESLint because it brings in a lot of waste of time discussing between ; or not and I don't have time for that.