ECMAScript 6 Modules

[z3dev]

Expected Behavior

It may be time to move to ES6 Modules as the latest browsers (from almost one year ago) now support ES6 modules, and NODEJS has support for ES6 modules as well. (MAN! I hate to submit this!)

See #391

Browser Support https://www.sitepoint.com/using-es-modules/

Comparison of ES6 and ComonJS Modules https://medium.com/@giltayar/native-es-modules-in-nodejs-status-and-future-directions-part-i-ee5ea3001f71

Reference http://2ality.com/2014/09/es6-modules-final.html

Actual Behavior

Everything is current comprised and composed from CommonJS modules. There is no support for ES6 modules, and the components of OpenJSCAD cannot be used as ES6 modules

Steps to Reproduce the Problem

1. TBD

Specifications

• Version: V1 (all versions)
• Platform: ALL
• Environment: ALL

[Digicrat]

Has there been any recent thoughts or work on ESM support? Are there any technical issues preventing such an upgrade/refactor? That is, aside from the obvious non-trivial time it would take to actually implement what would at best be a straight-forward but tedious and time-consuming upgrade.

ESM modules have been supported by NodeJS for a while now and make it relatively easy to develop complex JS code that runs in both the browser (for all reasonably up-to-date browsers) and node. I haven't used this project for long (though quickly becoming a fan), but some likely advantages to ESM support include

• Easier import/integration with other projects using standard import syntax
• Option to potentially eliminate a transpilation phase for easier browser-side development/debugging
• Resolve issues with loading multi-file designs in browser (https://github.com/jscad/OpenJSCAD.org/issues/674), and potentially simplifying your the js-file load process into a simple dynamic import().

[z3dev]

@Digicrat Thanks for the support!

ESM support is definitely in the plans but as you mentioned, there’s a massive refactoring required on the code base. Mixing CommonJS and ESM just doesn’t work. So, everything has to move to ESM in a kind of 3.0 Big Bang.

I’d be supper supportive if you’d like to work on this. There’s currently only two of us working part time on JSCAD so any progress is slow.

Alternately, reworking the build using Rollup would allow the libraries to be published as ESM modules. This might be a quick and easy improvement.

[hrgdavor]

Such work also hides some extra pitfalls that we do not even know now.

I converted a very small project to ESM, that is also using ava for testing and there was an issue that forced me to always write imports with full js name for local dependencies. This was easy to work around, but is interesting to know.

as @z3dev mentioned, easier step forward would be supporting esm as output, and I have also found an CDN that does this automatically.

https://medium.com/@m4jp6tp6/using-esm-syntax-to-import-js-packages-from-a-cdn-skypack-52d3344c07a0 https://www.skypack.dev/ https://www.skypack.dev/view/@jscad/modeling

import jscadModeling from 'https://cdn.skypack.dev/@jscad/modeling'

[anoblet]

I would be incredibly interested in this!

[z3dev]

I would be incredibly interested in this!

V3 branch is full import/export, but work in progress.

[hrgdavor]

One more thing to consider doing for V3 is to flatten exports in @jscad/modeling ... current hiararchical model confuses for exampel vscode and will likely confuse other editors that can do import autocomplete.

for example if you want to import sphere now in vscode

you will get an import that breaks script execution in some instances

with flat exports of jscad modeling functions, this would be simpler

I can aslo attest from my usage over the time, it was extra tedious to remember where some function is... is it in primitives or in booleans or in geom ...

[z3dev]

Duplicate. See #1166 for discussions.