Feature request: Import support, through file names and esm or --experimental-modules

It’s crazy that runkit doesn’t support most modern front end javacript, at all.

There are 2 potential solutions,

  1. Allow us to name parts of the notebook as files… then we can import them with esm
  2. A checkbox to enable the --experimental-modules flag
2 Likes

Hi @hesygolu,

The reason we don’t support this yet is precisely because it is an experimental feature. In fact, it only showed up in its bare bones form very recently in node and is still very unfinished (and arguably not in an entirely usable state). Had we supported any of the previous, now abandoned, incarnations, we’d have a bunch of notebooks that don’t work or would require strange bridging of old proposed solutions vs. current, theoretically stable (but I wouldn’t be surprised if it changes yet again), solution. In my experience most of the “real world” use of esm has been through transpilers (which don’t necessarily match the semantics of “real” import) and things like the “esm” package from node. We are also not terribly excited in betting on any particular userspace implementation.

We are working on ways to arbitrarily set any node flag, which should alleviate this concern in theory, but the reality is that that node ecosystem isn’t really there on esm yet. Is there a particular package that you are unable to use because it is esm? If so, it could certainly help us in determining the right way to move forward.

Thanks,

Francisco

1 Like

@tolmasky The npm esm module is a pretty good substitute from what I can see:

const esm = require("esm")(module)
global['window'] = global  // package-specific workaround, not general to all modules
const Color = esm("colorjs.io").default

I recommend adding a code snippet like that to the “import not supported” message as a workaround.

For what it’s worth… here’s what I do… yeah you lose syntax highlighting… but the errors are not half bad and it’s fast and it works with the unique native loader and it’s synthetic modules, and could be easily adapted for the ts-node loader.

https://runkit.com/hesygolu/60ca6ecc0bfbaa001a8fd3fa

Basically,

  • I require a module, any module
  • I read where it is
  • I symlink node_modules to that location
  • I write a michael jackson file
  • I run the michael jackson file

Yes, this still has access to all modules without the need to NPM install

2 Likes

ES modules have been stable since node v14. I think it’s high time to support them in runkit :slight_smile:

WDYT?

1 Like

We will be supporting es modules in RunKit, work has already begun on the feature.

Unfortunately it’s not as simple of just flipping a bit to turn it on. RunKit runs a lot of source transforms to make notebooks work the way they do, several of those need to be updated. We also need to add our hooks so that the es module loader can talk to module-fs (which saves you from having to manually install the packages you use).

Finally, on a personal note, while node might consider es modules “stable”, I do not. In our own testing (specifically to add support in RunKit) we’ve discovered bugs in v8’s implementation and file bugs against v8, but ultimately those issues are outside of RunKit’s control.

We do understand that more and more packages are being published that rely on es modules and that RunKit’s slow uptake on this issue is frustrating for folks. For that I do apologize, I don’t want to give you a timeline that we’re unable to meet, but we don’t expect this feature to take much longer.

- Randy

2 Likes

Any updates here? Timelines, roadmap? :slight_smile:

2 Likes