When using version 0.1.0, projects needed to polyfill URL and URLSearchParams as they were not implemented in the runtime

In version 0.2.0 these globals are now implemented but when building a project which tries to still polyfill these features, a Wizer error is thrown:

Error: failed to initialize JS

Caused by: 0: the wizer.initialize function trapped 1: wasm trap: unreachable wasm backtrace:

I confirmed this was the polyfills by commenting out this one line in my project and the project then being able to be compiled:

globalThis.URL = require("core-js/features/url");

I assume this means that the globals are currently frozen intrinsics, is this an intentional decision or should these be writable and configurable?

When setting set-cookie headers with header.append() there can sometimes be an issue where the set-cookie header is serialised into one header which is comma seperated:

This is not accepted as multiple cookies by browsers, after some digging I have found that this only happens when using a Header object which is then passed as a HeaderInit object when creating a response.

This works (creates multiple headers):

addEventListener("fetch", (event) => {
  let r = new Response("Hello");

  r.headers.append("Set-Cookie", "test=1");
  r.headers.append("Set-Cookie", "test2=2");
  r.headers.append("Set-Cookie", "test3=3");
  
  event.respondWith(r)
});

This does not (single comma separated header):

addEventListener("fetch", (event) => {
  let h = new Headers();

  h.append("Set-Cookie", "test=1");
  h.append("Set-Cookie", "test2=2");
  h.append("Set-Cookie", "test3=3");
  
  event.respondWith(new Response("Hello", {
    headers: h
  }))
});

Bumps @actions/github from 5.0.3 to 5.1.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The below constructors will now throw an error if called as plain functions as per their specifications:

• CompressionStream
• Headers
• Request
• Response
• TextDecoder
• TextEncoder
• TransformStream
• URL
• URLSearchParams

These constructors can now only be called via new or Reflect.construct

I wasn't sure what we want to do with the Fastly specific constructors such as CacheOverride so I have left them as-is

If I compile a syntactically valid javascript file that is still not valid we get a wizer error. However the exit code is 0.

Example input index.js:

spaghetti

output of js-compute-runtime --skip-pkg bin/index.js bin/main.wasm:

Exception while evaluating JS: (new ReferenceError("spaghetti is not defined", "<stdin>", 1))
  @<stdin>:1:29
  @<stdin>:1:121

Error: failed to initialize JS

Caused by:
    0: the `wizer.initialize` function trapped
    1: Exited with i32 exit status 1
       wasm backtrace:
           0: 0x3d82a1 - <unknown>!<wasm function 8744>
           1: 0x3d9434 - <unknown>!<wasm function 8760>
           2: 0x1c23a - <unknown>!<wasm function 300>
           3: 0x1bfd5 - <unknown>!<wasm function 298>
           4: 0x1c554 - <unknown>!<wasm function 303>
       
Wizer failed with status: exit status: 1

This is the correct error but the status code is 0:

...
Wizer failed with status: exit status: 1
 
➜  echo $?
0

This makes it impossible for tooling to detect build errors.

Added more meaningful messages to hostcall errors

The mapping from error code number to message comes from https://docs.rs/fastly-shared/0.6.3/src/fastly_shared/lib.rs.html#35-96

Resolves https://github.com/fastly/js-compute-runtime/issues/11

Hi, Following #10, I tried to reproduce a clone response function using ReadableStream::tee(), making 2 new responses from one. The function looks like that:

function cloneResponse(response) {
    const teedOff = response.body.tee();
    return {
        currentResponse: new Response(teedOff[0], { headers: cloneHeaders(response.headers), status: response.status }),
        newResponse: new Response(teedOff[1], { headers: cloneHeaders(response.headers), status: response.status }),
    }
}

By doing that, I can read the responses body using the ReadableStream::getReader(), they are not locked. But if I want to use the Response::json(), Response::text() or Response::arrayBuffer() instead of the reader, I get this error:

Aug 12 15:57:25.102 ERROR request{id=0}: WebAssembly trapped: wasm trap: unreachable
wasm backtrace:
    0: 0x5a6b - <unknown>!<wasm function 69>
    1: 0x593c - <unknown>!<wasm function 68>
    2: 0x11d6e - <unknown>!<wasm function 181>
    3: 0x129f1 - <unknown>!<wasm function 186>
    4: 0x384ca - <unknown>!<wasm function 475>
    5: 0x316ee - <unknown>!<wasm function 455>
    6: 0x299a9 - <unknown>!<wasm function 452>
    7: 0x387f9 - <unknown>!<wasm function 475>
    8: 0x3b701 - <unknown>!<wasm function 498>
    9: 0x177517 - <unknown>!<wasm function 3190>
   10: 0x96905 - <unknown>!<wasm function 1403>
   11: 0x1236ff - <unknown>!<wasm function 2376>
   12: 0x384ca - <unknown>!<wasm function 475>
   13: 0x3b701 - <unknown>!<wasm function 498>
   14: 0xa5a0e - <unknown>!<wasm function 1557>
   15: 0xfc9a5 - <unknown>!<wasm function 2121>
   16: 0x142cb - <unknown>!<wasm function 219>
   17: 0x3eb380 - <unknown>!<wasm function 8540>
   18: 0x140cf - <unknown>!<wasm function 218>

Am I doing something wrong ? Thanks !

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

Bumps typedoc from 0.21.10 to 0.23.21.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps env_logger from 0.9.1 to 0.9.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Consider the following code that works as expected:

class Base {
  fn() { return 'fn'; }
}
class Derived extends Base {
  constructor() {
    super();
    this.foo = () => { return 'foo'; };
  }
  bar() { return 'bar'; }
  get baz() { return 'baz'; }
}

const obj = new Derived();
console.log(Object.getOwnPropertyNames(Base.prototype));    // constructor,fn
console.log(Object.getOwnPropertyNames(Derived.prototype)); // constructor,bar,baz
console.log(Object.getOwnPropertyNames(obj));               // foo
console.log(obj.fn());                                      // fn
console.log(obj.foo());                                     // foo
console.log(obj.bar());                                     // bar
console.log(obj.baz);                                       // baz
console.log(obj.foo === undefined);                         // false
console.log(obj.bar === undefined);                         // false
console.log(obj.baz === undefined);                         // false

When you try to do the same thing by extending builtins:

class MyRequest extends Request {
  constructor(input, init) {
    super(input, init);
    this.foo = () => { return 'foo'; };
  }
  bar() { return 'bar'; }
  get baz() { return 'baz'; }
}

const request = new MyRequest('https://www.google.com/');
console.log(Object.getOwnPropertyNames(Request.prototype));   // constructor,method,url,version,headers,body,bodyUsed,arrayBuffer,json,text,setCacheOverride
console.log(Object.getOwnPropertyNames(MyRequest.prototype)); // ** constructor,bar,baz
console.log(Object.getOwnPropertyNames(request));             // foo
console.log(request.url);                                     // https://www.google.com/
console.log(request.foo());                                   // foo
console.log(request.bar());                                   // ** Error: request.bar is not a function
console.log(request.baz);                                     // ** undefined
console.log(request.foo === undefined);                       // false
console.log(request.bar === undefined);                       // ** true
console.log(request.baz === undefined);                       // ** true

Look at the logs relating to bar and baz (marked with asterisks above). You can see that the two methods (bar method and baz getter) added through the class definition are added to the prototype but have undefined values. Note that the property added in the constructor (foo) does work, however.

The same problem happens whether we are extending Request, Response, Headers, URL, URLSearchParams, etc. so I believe it is just for the builtins, and I believe it's a bug.

Missing some instructions on README for the build?

I encountered errors during the following build commands on README.md:

$ git submodule update --recursive --init
$ (cd c-dependencies/spidermonkey && sh download-engine.sh)
$ cargo build --release // ERROR

Not sure if this is common for other people, but I share what I've done, for the record.

• Install cbindgen https://github.com/eqrion/cbindgen#quick-start
• Install wasi-sdk and export the sdk path https://github.com/WebAssembly/wasi-sdk#install $ export WASI_CXX=${WASI_SDK_PATH}/bin/clang++
• Modify Makefile

  -ifdef DEBUG
  +DEBUG ?= false
  +ifneq ($(DEBUG), false)
  

  *cargo exports DEBUG=false when running build.rs with --release flag

Environment:

• hash: dbd9386
• platform: M1 Mac (darwin, arm64)

This adds a new --component flag to the runtime CLI, that when provided will output a full component binary for the runtime instead of a core Wasm binary.

The component binary uses the latest version of the wasi-preview2 adapter to adapt the WASI imports, fetched from the releases of https://github.com/bytecodealliance/preview2-prototyping.

Component generation along with WASI 1 -> WASI preview 2 adaption is only after Wizering so that we retain full compat with the current core Wasm Wizer process.

The WASI adapter is applied using a build of wit component provided by js-component-tools providing wasm-tools for JS, so js-component-tools is introduced as a dependency of the runtime in the process (~20MB, no dependencies).

Strictly speaking, this completes the task of generating a js-compute-runtime Wasm component.

Whether this should be merged is a question of if we want to introduce the extra js-component-tools dependency for non component installers. It might not be such an issue, or we could maintain this branch.

Review / feedback / thoughts / comments very welcome.

After executing the script, we perform a non-shrinking GC. Testing indicated that shrinking here caused more writes to 4kb pages than a normal GC, but let's verify that this is the case.

Currently we have the following line commented out during initialization, and we should check to see if it's worth uncommenting:

JS_SetGCParameter(cx, JSGC_MAX_EMPTY_CHUNK_COUNT, 10);

Verify that it's better to perform a shrinking GC during initialization before running the script, as testing indicated. Running a shrinking GC caused fewer 4kb pages to be written to when processing a request, which suggests that memory was less fragmented as a result.