OpenJSCAD.org
OpenJSCAD.org copied to clipboard
jscad
Use ECMAScript modules instead of the current system.
ECMAScript modules have landed to releases of most of browsers. I guess it's time to drop support of old browsers (in fact they support ECMAScript modules, but the support is under a pref disabled by default) and use modules instead of the currently used dirty approach.
Hi @KOLANICH !
-
do you mean instead of include() ? or for the code base ?
-
for the code base we will not be switching to es6 modules until they are fully supported in node.js without transpiling
-
for replacement of include() we are working on adding require() support (already present in the desktop & cli versions). Sadly the support in browsers is both a bit too recent and does not allow for import-ing dynamically created code (at least according to my tests around 2 months ago). main solution for dynamic code like the jscad code seems to come from the
import()statement which is still not standard. If you know of other solutions, please let us know !
typescript allows to compile to a certain version of javascript and a certain module system using just --target and --module arguments to the command line interface (or same parameters defined in tsconfig.json)
same code in typescript
// input.ts
import { Polygon3D } from './Polygon3D';
will compile to the following javascript depending on the --target and --module arguments
// output.js with --target esnext --module commonjs
import { Polygon3D } from './Polygon3D';
or
// output.js with --target es3 --module commonjs
const { Polygon3D } = require('./Polygon3D');
or
// output.js --target es3 --module amd
define(["require", "exports", "./Polygon3D"], function (require, exports, Polygon3D) {
});
it's very relevant if you want to cover most platforms and browsers, by writing code once and compiling it to a specific platform as many times as needed, rather than being stuck with one platform by writing js by hands
I would really appreciate If you could try to understand the problem at hand instead of trying to evangelise for typescript to be honest :) how to load modular user created code is not related to / specific to Typescript
typescript solves whatever problem you have with the modules, and you do have problems, namely your code is written for commonjs module loader for node.js, it doesn't take advantage of the new es module system, neither would it work with AMD module loader in browsers (without repacking it with webpack or something)
@aleksey-bykov do you even understand the difference between the code that we write and the userspace code ? different needs, different issues
i am a user of your code, and i've been struggling to make use of it, and with issues like this it looks i am not alone, i really can't see why you are holding off, your point that you need less tools not more doesn't make much sense on its own, you need less tools to accomplish what? tools are made to boost productivity or get faster and with less pain to wherever you are heading
do you mean instead of include() ? or for the code base ?
I mean no include, no require, but ES import and export.
I'm not familiar with the code, I just opened the file and saw there the code generated by bundlers and some hardcoded paths, it may be hard to debug and develop this code.
for the code base we will not be switching to es6 modules until they are fully supported in node.js without transpiling
I guess this should depend not on full support but on support of the subset you actually use.
Sadly the support in browsers is both a bit too recent and does not allow for import-ing dynamically created code (at least according to my tests around 2 months ago).
Does even creation of a script tag not work?
Well, well... looks like we may have to review this soon. I picked this up from a technical blog.
ESM support is slated to land, unflagged, in Node v10 anytime between October 2018 and April 2020.
