The plan for Flowscripter has always included the following goals:

• Use TypeScript.
• Use dynamic import of ES modules.
• Rely on existing module dependency directives to auto-install plugin dependencies i.e. not inventing a new module dependency framework.
• Providing Flowscripter as a single downloadable binary with no need for pre-installed dependencies e.g. Node.js, ffmpeg.
• Support native extensions written in Rust.

To meet these requirements Flowscripter started with:

• TypeScript running on Node.js.
• Requiring Node.js 10.x onwards which had the first experimental support for ES modules.
• The esm-dynamic-plugins library made use of the npmjs.com repository and Node.js package.js definitions. For browser runtimes, using https://unpkg.com was the intention.
• The intention was to use nexe to build a single distributable binary.
• The intention was to use NodeJS N-API C++/C addon support and develop Rust based native add-ons as per this tutorial.

Of course with the above technologies, came the usual (and painful) need to configure and debug a build toolchain providing TypeScript, a test framework (Jest), a packaging system (RollupJs) and a documentation generator (TypeDoc).

More difficult was the need for these tools to support ES modules natively (or via transpiling) and for the Flowscripter ES Modules to depend on existing non-ES module NodeJS packages …. I think I spent just as much time getting the toolchain working together as I did writing ‘actual code’…

Although, the Flowscripter ‘actual code’ it still in a state of infancy, the main concerns so far with the above are the following:

• Making use of the NodeJS package.json and npm repository either necessitated:
  • Calling out to a locally installed npm thereby defeating the purpose of a single installable binary.
  • Importing the underlying npm implementation: a horrible rabbit hole I discovered and then exited!
  • Implementing support from scratch - which was done but with some severe limitations (see here and here).
• Despite the excellence of nexe, support for native addons, externally sourced modules and ESM modules still seems to be work in progress… see here, here and here.

Around the time of starting out on Flowscripter I had seen the announcement of Deno. Obviously bleeding edge would have been an understatement at that point…

However, since then, time has passed (mostly working on the toolchain issues mentioned above, or more importantly on actual paid work….) and Deno v1 has been released.

It’s tempting. Let’s review given the initially stated Flowscripter goals and the current concerns for the Node.js based implementation:

• TypeScript ✅
• ES Modules ✅
• Rust plugins ✅
• Compiled executables ✅
• Simple dependency mechanism ✅

Additionally, the support for importing a module from a URL would (hopefully) completely obviate the need for esm-dynamic-plugins to implement separate a UrlPluginRepository.ts and NodeModulesPluginRepository.ts.

Of course there are arguments against Deno. These are mostly based on it’s relative immaturity. Fair enough, you don’t want to back the wrong horse… And also is it really ready for production?

To answer that, I’m going to take some time out to do an analysis of whether the above mentioned features can currently meet the Flowscripter goals and my concerns on the current path taken. Findings to follow….

P.S. I’m also going to take time to make use of the fact that GitHub seems to be swallowing the CI/CD world. Hence I’m planning to port away from npmjs.com (well maybe with Deno this won’t be relevant - any hoo…), Travis and Renovate and use GitHub for everything.