Support CoffeeScript on the new `deno` JavaScript engine

[shreeve]

This is a feature request to see what is needed to support running CoffeeScript on the new deno js engine (see https://deno.land/).

The original author of node is Ryan Dahl (@ry). After a decade of experience, there are several things that he would do over if he could do it all over again de novo (thus, the name deno). There is an excellent video where he describes the rationale to start from scratch and build a modern, secure JavaScript runtime on V8. The deno engine (analogous to what node is), is a single binary executable written in rust that embeds the V8 engine and supports ES6 modules natively. Package management is also greatly simplified.

The deno engine has native support for additional languages such as TypeScript. It does this by automatically transpiling TypeScript code within an isolate and then feeding the transpiled js to the deno engine. Normal JavaScript is fed directly to the V8 engine. While deno isn't done yet, it would be great to be able to bring the beauty and succinctness of CoffeeScript to deno and this issue is an initial attempt to see what is needed to do so.

What I am requesting is to see if we can add support for CoffeeScript to be supported as a first-class isolate like TypeScript.

@GeoffreyBooth or @jashkenas, is this an ok place to raise the question?

[GeoffreyBooth]

I think this is a fine issue to hold discussion about making this happen, sure. I don’t see why we wouldn’t want CoffeeScript supported in deno if that were possible.

CoffeeScript is currently a CommonJS NPM package, so that version wouldn’t be runnable in deno; but the browser version would. I guess the question is, does deno support third-party loaders equivalent to its internal TypeScript loader? If so, then you just package up the browser compiler inside whatever wrapper deno needs for a loader. If not, you’ll need to submit a PR to deno itself to add CoffeeScript as another first-class citizen alongside TypeScript. I can imagine that might be a much more delicate proposal.

I’m a member of the Node.js modules working group trying to bring ES modules support to Node without breaking CommonJS (or CoffeeScript or TypeScript 😄). At some point Node will support ES modules, and when that happens I’m interested in having the CoffeeScript NPM package export an ES module version.

[jashkenas]

At some point Node will support ES modules, and when that happens I’m interested in having the CoffeeScript NPM package export an ES module version.

Very exciting, Geoffrey!

[shreeve]

@GeoffreyBooth - Does the new CoffeeScript 2.4.0 now support this ES module version? I think it does, based on your comments. How hard is it to produce a rollup-style minified version that could be put on a CDN?

[GeoffreyBooth]

It’s here: https://coffeescript.org/browser-compiler-modern/coffeescript.js

That’s hosted by GitHub Pages, so it doesn’t cost us anything, so you should feel free to link to it. I forgot to include that file in the bundle I published to NPM (d’oh) so it’ll be included there in 2.4.1 (#5186) whenever that gets released, and then the file will be accessible from unpkg and jsdelivr and other sources like that.

[shreeve]

Awesome! Thanks Geoffrey.

…

On Mon, Apr 1, 2019 at 4:32 PM Geoffrey Booth ***@***.***> wrote: It’s here: https://coffeescript.org/browser-compiler-modern/coffeescript.js That’s hosted by GitHub Pages, so it doesn’t cost us anything, so you should feel free to link to it. I forgot to include that file in the bundle I published to NPM (d’oh) so it’ll be included there in 2.4.1 (#5186 <#5186>) whenever that gets released, and then the file will be accessible from unpkg and jsdelivr and other sources like that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5150 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIuG5xP7f-kSOrJf6r9P8BtzBlqhmdYks5vcoj3gaJpZM4aIWxR> .

[shreeve]

Do those services (unpkg, jsdelivr, etc) also minify? I think the file was 531k or so otherwise. Not sure if it’s something that should be run through rollupjs or something like that. — On Mon, Apr 1, 2019 at 4:34 PM Steve Shreeve <steve.shreeve@gmail.com> wrote:

…

Awesome! Thanks Geoffrey. On Mon, Apr 1, 2019 at 4:32 PM Geoffrey Booth ***@***.***> wrote: > It’s here: > https://coffeescript.org/browser-compiler-modern/coffeescript.js > > That’s hosted by GitHub Pages, so it doesn’t cost us anything, so you > should feel free to link to it. I forgot to include that file in the bundle > I published to NPM (d’oh) so it’ll be included there in 2.4.1 (#5186 > <#5186>) whenever that > gets released, and then the file will be accessible from unpkg and jsdelivr > and other sources like that. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#5150 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAIuG5xP7f-kSOrJf6r9P8BtzBlqhmdYks5vcoj3gaJpZM4aIWxR> > . >

[GeoffreyBooth]

I’m not aware that they minify. We could produce a minified version as part of our own build process; the non-ES module version of the browser compiler is minified, there’s no reason the ES version shouldn’t be. We’d need to make sure that the import and export statements are transpiled into CommonJS though.

Where would this be used where file size/download time would be a concern? The only places where I expect the browser compiler to be used are the CoffeeScript docs and sites like jsfiddle and codepen.

[kitsonk]

Hey! Just piping in on this issue. Contributor to Deno and look a lot at the compiler APIs. We have denoland/deno#1739. In order to get "good" CoffeeScript support, we would want to plug in the CoffeeScript compiler to the yet to be public compiler API. This would give the equivalent level of support that the TypeScript compiler has which includes the ability to fetch remote modules and have automatic caching.

We have most of the fundamentals almost there and I will be working on it in the near future. It is planned that the public API for compiler will run as a web worker. The options passed to the web worker would define what media types and extensions should be routed to the compiler when attempted to be loaded. Those will be sent to the compiler and the compiler is expected to return an ESM module which will then be injected into the runtime environment.

A compiler should have a single bundle of JavaScript which interfaces to the public API.

[shreeve]

It would be wonderful to have excellent (first class, on par with TypeScript) support for CoffeeScript in deno. How far off is the public API for deno?

…

On Mon, Apr 1, 2019 at 5:18 PM Kitson Kelly ***@***.***> wrote: Hey! Just piping in on this issue. Contributor to Deno and look a lot at the compiler APIs. We have denoland/deno#1739 <denoland/deno#1739>. In order to get "good" CoffeeScript support, we would want to plug in the CoffeeScript compiler to the yet to be public compiler API. This would give the equivalent level of support that the TypeScript compiler has which includes the ability to fetch remote modules and have automatic caching. We have most of the fundamentals almost there and I will be working on it in the near future. It is planned that the public API for compiler will run as a web worker. The options passed to the web worker would define what media types and extensions should be routed to the compiler when attempted to be loaded. Those will be sent to the compiler and the compiler is expected to return an ESM module which will then be injected into the runtime environment. A compiler should have a single bundle of JavaScript which interfaces to the public API. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5150 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIuG8A1Yx2S02x8HPyGXlMx4sy4pf-vks5vcpPAgaJpZM4aIWxR> .

[GeoffreyBooth]

@kitsonk Thanks for chiming in! We appreciate the support.

CoffeeScript’s Node API today is described here: https://coffeescript.org/#nodejs-usage. Currently it takes a string (CoffeeScript source code) as input and returns an object (JavaScript source code, and source maps) as output. That’s it.

I’ve spent a little time working in the Meteor plugin for CoffeeScript; it wraps the CoffeeScript compiler in a class that handles caching and other niceties. Would your compiler API be like that? Or would the CoffeeScript compiler itself, or something that wraps it, be expected to handle caching? What about resolving URLs of import statements?

[kitsonk]

The privaliged side of Deno (Rust) would handle the module resolution and caching. I would suspect given the NodeJS API, that the wrapper would be super light. After a compiler is instantiated with something like this:

new Worker("https://coffeescript.org/browser-compiler-modern/coffeescript.js", {
  deno: {
    extensions: [ "coffee" ],
    media_types: [ "application/vnd.coffeescript" ]
  }
});

The web worker would receive an onmessage which would contain a payload of a Module Specifier and a Referrer. The compiler would need to use a privileged API to fetch the contents of module (fetchModuleMetaData) supplying the same module specifier and referrer. That would cause the privileged side (Rust) to resolve the module, including retrieving a remote module from the network, and returning the fully qualified module specifier, the media type, and any source code. If the compiler needs other modules meta data to fully transpile the code, it can continue to request additional modules (e.g. TypeScript has to resolve all dependencies in order to properly type check a module).

The compiler is then expected to pass back an ESM module and a source map.

The compiler will only be called to transpile a module if Rust has determined that either the cache is invalid or that the module isn't cached. When the data is returned, Rust will handle caching it locally.

When the module is returned, the privileged side will inject the module into the V8 runtime and V8 will resolve any additional dependencies, if those dependencies resolve to an extension or media type covered by the compiler, it will then repeat the cycle.

We haven't thought through the details of externally configuring a compiler yet, so that you would "always" have it at startup.

As far as a timeline, I have another piece of work in my backlog before really starting the public compiler API, and we need full web worker support which is about to land in Deno. So I expect I would really start working on it in a week or two. We always talked about using CoffeeScript as the "use case" for proving out the public compiler API, so this was timely.