jstime / jstime

another runtime

jstime

Another JavaScript Runtime

Using the binary

You can find the latest jstime binary on the release page

Alternatively you can install with cargo

$ cargo install jstime

As a repl

$ jstime

Welcome to jstime!

>>

Run a script

$ cat hello-world.js
console.log("hello world");

$ jstime hello-world.js
hello world

Embed it!

Check out the README.md for jstime-core for instructions on how to embed jstime in your rust application!

Current Project Team Members

for information about the governance of the jstime project, see GOVERNANCE.md.

Chair

• MylesBorins - Myles Borins (he/him)

Collaborators

• bengl - Bryan English (he/him)
• bdougie - Brian Douglas
• codebytere - Shelley Vohr
• devsnek - Gus Caplan
• EstebanBorai - Esteban Borai
• jalafel - Jess Tran
• MylesBorins - Myles Borins (he/him)
• solumos - Tom Hadley

TODO

• fetch
• Some sort of system interface, maybe WASI

jstime's Issues

Implement HTML standard timer APIs

As documented in https://html.spec.whatwg.org/multipage/timers-and-user-prompts.htm

@bdougie brought this in #27 (comment)

This would include:

setTimeout()
setInterval()
clearTimeout()
clearInterval()

In deno this is how it is implemented

https://github.com/denoland/deno/blob/master/cli/global_timer.rs
https://github.com/denoland/deno/blob/master/cli/rt/11_timers.js

Definitely interesting that the JavaScript runtime extensions are implemented in deno_cli not deno_core

Support Top-Level Await

Now that we have an ESM loader, of course we are going to want Top-Level Await

I do not believe that the existing loader will be able to support TLA out of the box @bengl and @devsnek might be able to chime in a bit about what work would need to be done to get that working.

Implement ESM

Currently there is no module loader. It would be nice to support ESM. Basic support for file system resources will likely be the easiest MVP

Implement WHATWG Fetch API

This one is going to be a doozy since it implies network access, streams, event pointers, promise cancellation.

It is a lot of work, but let's make fetch happen!

Support WHATWG Streams

It seems to me that having a streams interface in jstime would be nice.

/cc @mcollina @domenic

Broadening collaborators and creating open governance

Right now I'm the only one with commit access. I definitely don't want this project to be a BDFL. I do have a high level ideology for jstime, primarily that it should do as little as possible and use standard interfaces as much as possible. With that said I have a distinct feeling that the project will evolve and adapt based on those who are involved.

With this in mind, I'm going to start drafting out a governance model for how we handle both decision making and conflict resolution. I would be particularly interested in designing a governance model based on rough consensus.

Some initial folks I would like to nominate to become collaborators include:

• @bengl
• @bdougie
• @codebytere
• @devsnek
• @EstebanBorai
• @solumos

Event Loop

Probably need one of those 😅

Implement WHATWG URL api

Related to #44

While not entirely necessary based on the current jstime feature-set, having the URL api seems like a reasonable platform builtin, PTAL at https://github.com/jstime/jstime/tree/main/core/src/builtins for examples of our existing built ins console and queue microtask

https://url.spec.whatwg.org/

Stack traces no longer working

Seems like we really do need some sort of basic test runner to avoid regressions like this

It would appear that b7a6d99 regressed our stack trace support

/cc @devsnek

Release action is busted

This is due to how it uses environment variables to store information about the version that can eventually be used when naming assets.

8ba3619 was an attempt to fix this, it didn't work. Needs to be revisted

REPL tab completion

Tab completion in the REPL would be quite nice

Testing

We don't have any tests, we should have tests.

jstime_core: Modularizing builtins

Right now we only have 2 built ins, console and queue_microtask.

We manually add them as "builtins" in jstime_core and include them when they are snapshotted. This works for now, but is arguably not the most extensible or modular approach to the problem.

What if jstime_core had 0 builtins. Instead it had an API for defining built-ins, those built ins extending a base built-in class that jstime would know how to instantiate. If we had an extendable Builtin class (struct?) individuals could make creates that exposed their extension as a module which could just be passed to jstime_core at instantiation time

---

Super bad idea of what an API for defining builtins could looks like

mod jstime_console as console;
use jstime_core as jstime;

fn main() {
  jstime::init(None);
  let mut options = jstime::Options::default();
  options.builtins.push(console);
  
  let mut jstime = jstime::JSTime::new(options);
  jstime.import("./path/to/some/file.js");
}

---

Super bad idea of what a Builtin class could look like

struct Bultin {
  jsSource: char *inventory[], //(list of js files to run)
  nativeBindings: char *inventory[], //(list of functions to bind)
  snapshot: bool, // (whether to include in snapshot)
}

Then the implementation could create the functions that are to be bound and referred to in nativeBindings?

MacOS Binaries need to be notarized

I can't wrap my head around why, but when testing the MacOS built binaries on my local machine it take many seconds to start. This is not the case with a locally built binary using the exact same commands. I'm confused

Improve argument parser

The current parsing is laughable naive.

We should be able to parse various incoming arguments including feature flags

Should we allow PRs with no review to land after a certain amount of time?

#48 has been open for 5 days, and we have not been able to land it due to lack of review.

How do folks feel about introducing governance that would allow unreviewed PRs without objections to land after a certain amount of time. E.g.

If a pull request has been open for 5 days it can land without review as long as there are no objections.
If another collaborator would like to revert the PR after landing they can do so without review within 48 hours.

The above text give flexibility to both keep things moving and a window for reverting the change without review if someone comes in late. In general I'm a big +1 on making reverts easy and non-controversial.

Implement WHATWG console API

V8 instantiates console but all the functions are noops. I believe that an inspector needs to be set up in order to functionally log.

REPL History

Currently there is no history in the REPL. This is supported by the library we are using rustyline, how to implement it can be found in the docs https://docs.rs/rustyline/6.2.0/rustyline/

Improve the docs

Currently the documentation for jstime is primarily in the readme. As the API expands it will be good to document using rustdoc so we can have something a bit nicer for folks to refer

Release builds don't have semver in asset name

Need to refactor action

Implement WASI system interface

If we want to do anything beyond running code in the JS VM we are going to need a system interface and a way to bind native code to JS.

I like the idea of using WASI as the system interface and supporting WASM modules in the loader.

Errors in run JavaScript code still have exit code of 0

Right now we only print to stderr, but we don't modify the exit code when there are errors

https://github.com/jstime/jstime/blob/main/cli/main.rs#L46

store repl history between sessions

Currently we do not save repl history between sessions. Node.js stores history in $HOME/.node_repl_history.

rustyline does support saving + loading session data and it is documented in the readme

Print stack traces

Currently there are no stack traces being printed... it would be nice to have them

json modules

There is a proposal -> https://github.com/tc39/proposal-json-modules
It build on top of import assertions -> https://github.com/tc39/proposal-import-assertions

V8 does not yet support import assertions though AFAIK... but I also think that an embedder can choose if they need to require the import assertion or not, need to review the spec.

wasm modules

There is a proposal -> https://github.com/webassembly/esm-integration
Implementation in Node -> nodejs/node#27659

Compilation failure when installing via `cargo install jstime`

error: failed to build archive: bad archive: truncated or malformed archive (offset to next archive member past the end of the archive after member counters.o)

error: aborting due to previous error

error: could not compile `rusty_v8`.

To learn more, run the command again with --verbose.

This is due to an issue in rusty_v8. Attempted to fix in c911f02 but it didn't stick

Refs: denoland/rusty_v8#543

Are web-compat builtins actually a goal?

It seems to me that given an adequate lower-level interface, there's not much need for things like URL, fetch, etc. to be provided as builtins. I know this topic has been played out quite a bit in Node.js, but since this is a greenfield approach/project, I think this warrants of its own discussion.

I'm (at the moment) non-blockingly opposed (i.e. a -0 I guess) for adding WHATWG/W3C-specific builtins to the runtime as a base layer. I think it absolutely should be trivial to add such functionality and create environments that look enough like browsers to make browser code work.

Handle repl errors instead of blowing up process

Currently if there is an error in user code passed to the repl things blow up. Would be nice if it didn't.

Should we implement NAPI?

If we do end up implementing support fo WASI (#5) we may want to have a stable ABI for interfacing with V8. I'm not 100% if NAPI would be the best fit but if we can have WASI + NAPI native modules might be portable between jstime + node, which would be pretty awesome.

implement import.meta.url

we currently don't implement import.meta.url which would be nice to have, and potentially even useful at some point if we offer file system APIs 😂.

https://docs.rs/rusty_v8/0.9.1/rusty_v8/type.HostInitializeImportMetaObjectCallback.html and https://docs.rs/rusty_v8/0.9.1/rusty_v8/struct.Isolate.html#method.set_host_initialize_import_meta_object_callback are documenting the required API calls to V8

Here is it being set in deno https://github.com/denoland/deno/blob/master/core/es_isolate.rs#L84-L86

ESM Builtins

Blockers:

• https://bugs.chromium.org/p/v8/issues/detail?id=10855
• denoland/rusty_v8#449