Check out this notebook:
Class properties are not supported | RunKit
As you see it reports an error:
Class properties are not supported
Comment ça?
Node version is set to 17 (an overkill, but to be kind of safe). Of course tried 16, 14.
It doesn’t make any sense…
P.S. I also send a tweet on this to @runkitdiv but haven’t received a reply yet. Then discovered this community and decided to ask here.
Hi @onkeltem, we are in the process of supporting this. It has to do with the Babel 7 update we are working on (you can actually see our work on the actual Babel repo too). Everything has to go through Babel for the top-level await stuff (and a few other features, like JSX), so unfortunately even standard features can be blocked by it. The underlying Node does in fact support these features, as you can see by routing everything through eval:
const MyClass = eval("(class MyClass { height = 20; })");
const object = new MyClass();
object.height;
Just as an aside, class fields are not part of ES 6 (ES2015). They only reached stage 4 this year, and are thus part of ES2023, which is “ES14”. Sorry for the inconvenience, we will hopefully be pushing this out within a month.
Thanks for the answer @tolmasky
I didn’t realize it’s so complicated. I just saw the “node” label, and then was like: what?
But if it still gets processed through Babel, then it makes sense of course.
As for class fields in ES6 — it’s just another gap in my knowledge: I really thought that if I see something on MDN (w/o additional notes), it’s kind of part of ES6+ stuff 
E.g. MDN Classes
Maybe it’s worth displaying more info about your build stack? Such as Babel and the list of enabled proposals. In the title of I mean:
Maybe it’s worth displaying more info about your build stack? Such as Babel and the list of enabled proposals.
It’s better to think of it as part of the editor than part of the build stack. For example, we need a way to show syntax errors immediately vs. sending it to the server, spinning up node, trying to run the code, then sending back a syntax error if we receive it (especially since Node often has less useful syntax errors). We also use CodeMirror for editing on the client, but we wouldn’t want to show Node 17/Babel 6 (for editing)/CodeMirror 6/etc. We’re simply in an unfortunate transition where it was not trivial to update from Babel 6 to 7, and thus we’re temporarily “stuck” we Babel 6’s plugins. The real fix is for us to just actually make this work, so that you can actually use class fields, and for us to fix it in a way where we won’t be caught in this same situation in the future – which is exactly what we’re working on. It’s frustrating right now (trust me, even more so for us!), but we’re investing our energy into the precise issue you are running into and want a permanent fix. I do apologize that it sucks right now (people are starting to run into it precisely because many of these features are finally making it into the standard and spec).
I really thought that if I see something on MDN (w/o additional notes), it’s kind of part of ES6+ stuff
Sure, I mean, I guess then it’s also part of the ES5+ stuff 
The MDN Classes page will always show the latest additions to that category of features. If a new class feature gets added 5 years from now, it’ll go on that page too, but that won’t “ES6-ify” that feature (that is to say, if something touts itself as ES6 compatible, you shouldn’t expect it to have that ES2027 feature). Again though, the critique that we are missing it is completely valid – my only point is that saying that RunKit doesn’t support ES6 (vs. ES2023 or ESNext if you want an “evergreen” terminology) implies a 7-year old feature is missing, not a feature that arguably isn’t part of the standard yet (although again, the critique that we are missing “Node 14/16 or whatever features” is also a valid way of putting it, since Node sometimes incorporates features earlier than the standard). But I digress, this was meant like more of a fun fact to show the difficulty of dealing with JS features.
I got you! Take your time, and good luck! I’ll be rooting for you
The reason I feel really excited about runkit, is its notebooks approach.
It reminds me another similar UI — at https://observablehq.com/. But it’s all about D3 only, while runkit seems to be a sort of swiss-knife with all those packages which are always at hand.
Do you have plans on adding TypeScript support?
Thanks!
This is a tricky question. And somewhat gets into the above issues. The problem with Typescript is that it does in fact diverge from “Node”. We don’t have a trivial “ideal” of merely just supporting everything Node does at a given version, it in fact does form a matrix of (Node version, Typescript version) pairs. As such, this would require us to have something like what you described in the UI, allowing you to select your Typescript version separately from your Node version, and to theoretically be able to support those legacy versions in perpetuity (as we wouldn’t want to “deprecate” people’s old notebooks). Typescript’s history thus far has been to make some pretty big changes version to version, so we have to be careful about how we add this. We’re currently thinking about all this as part of the larger umbrella problem of “JS extensions”. In an ideal world, you could define any sort of pre-run step, whether its running a custom Babel plugin for a language proposal, or Typescript, etc. Of course, the more general you make it, the less user friendly it might be for people that “just want to use Typescript”. Anyways, we are very open to suggestions/requests/etc. in this space.
