Know how is the burden of NPM/Yarn/PNPM/Bun? Configuring sources, manually watching third-party libraries for TS->JS/.d.ts transpilation (due to third-party tsconfig.json being ignored) and embedded asset-copy-watch...

Yeah, well, I've finally surrendered to using TypeScript as a masked language (through the tsc API itself) called EScript (ES) for a platform called ZoneGFX for developing native apps and also enjoying a package manager similiar to Cargo's, where the build system is more automatic than NPM's.

What it might remind you of:

• Cargo
• Perhaps a bit of old Google Closure (in terms of the convention used for package names) and ECMAScript 4-ish.
• PIXI.js/Adobe AIR (DisplayList!)
• React.js (ZoneDS components!)

The EventRecord pattern above is possible and will offer type inference as was always normal in the web TypeScript APIs.

The project on-going efforts are private for now, but I may reconsider things up. Would be totally nice to be in team to shift the project faster, but, yeah, that's it. (I'll also have to implement a language server, but I guess it won't be that hard using the tsc API.)

About the package IDs and module specifiers: perhaps I'm that way because one of my first programming languages was ActionScript 3 back in 2015 and I miss its coding guidelines; so you may disregard my taste. And I also had a seemingly esocteric look at ECMAScript 4 back in 2017, so I'm really biased.

• import("org.generalrelativity.foam.sat") maps to <source-path>/sat/__mod__.es
• import("org.generalrelativity.foam.sat::SAT") maps to <source-path>/sat/SAT.es
• There are still relative-local imports like the ../../.. hell
• A package may import from its own package ID in the sources as if it were an absolute path.

Anyways, there will be few packages that use a scopeless simple ID (in that case, AFAIK just the platform's built-ins, for now).

1 post - 1 participant

Read full topic