Update documentation to mention compatibility with ES2022

[ekoleda-codaio]

Update the overview page to mention support for ES2022 language features, now that the Packs runtime has been updated to run on Node 18.

I tried updating compile.ts to target ES2022 directly, but ran into some errors. This is fine though, as esbuild will just downlevel any newer features.

[huayang-codaio]

I tried updating compile.ts to target ES2022 directly, but ran into some errors.

What error did you receive? Just curious. esbuild does mention that they support es2022.

[ekoleda-codaio]

What error did you receive? Just curious. esbuild does mention that they support es2022.

 ./node_modules/.bin/ts-node cli/coda.ts execute documentation/samples/packs/hello_world/hello_world.ts Hello "Eric" --vm=false                                      [16:16:58]
/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/insert-module-globals/index.js:114
            var e = new SyntaxError(
                    ^
SyntaxError: Unexpected token (511:13) while parsing /var/folders/kp/k5sf9p811dg_yxm73vqnd_sr0000gq/T/coda-packs-7530a212-3ad4-4067-b694-3cba08499be4yHNhln/esbuild-bundle.js while parsing file: /var/folders/kp/k5sf9p811dg_yxm73vqnd_sr0000gq/T/coda-packs-7530a212-3ad4-4067-b694-3cba08499be4yHNhln/esbuild-bundle.js
    at DestroyableTransform.end [as _flush] (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/insert-module-globals/index.js:114:21)
    at DestroyableTransform.prefinish (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_transform.js:138:10)
    at DestroyableTransform.emit (node:events:513:28)
    at DestroyableTransform.emit (node:domain:489:12)
    at prefinish (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:619:14)
    at finishMaybe (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:627:5)
    at endWritable (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:638:3)
    at DestroyableTransform.Writable.end (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_writable.js:594:41)
    at DestroyableTransform.onend (/Users/EricKoleda/code/packs-sdk/node_modules/.pnpm/[email protected]/node_modules/readable-stream/lib/_stream_readable.js:577:10)
    at Object.onceWrapper (node:events:627:28)

[huayang-codaio]

Thanks. I am also taking a look.

[huayang-codaio]

Actually. I am not exactly sure if the es2022 bundle will run in isolated-vm. We are running into this error because browserify doesn't accept some es2022 syntax.

Take a step back, we don't really need the target to be es2022 right? The goal is probably to allow monaco understand es2022 syntax (in the browser editor) but the bundle target (which is the binary that runs in isolated-vm) doesn't need to be es2022.

[ekoleda-codaio]

From what I can tell, browserify uses the package insert-module-globals which in turn uses an old version of acorn to parse the code, and that old version doesn't support newer ES2022 syntax. Issue here: browserify/insert-module-globals#88

[huayang-codaio]

I would suggest to stay on es2020 for the target for now. Let me take a quick look at monaco editor side.

From what I can tell, browserify uses the package insert-module-globals which in turn uses an old version of acorn to parse the code, and that old version doesn't support newer ES2022 syntax. Issue here: browserify/insert-module-globals#88

Right. Browserify is one issue. I am more worried if isolated-vm supports the full ES2022 syntax.

[ekoleda-codaio]

Take a step back, we don't really need the target to be es2022 right? The goal is probably to allow monaco understand es2022 syntax (in the browser editor) but the bundle target (which is the binary that runs in isolated-vm) doesn't need to be es2022.

Yes, that is my understanding as well. Targeting ES2020 will I believe create shims for newer language features, which in theory could be a bit slower than using the native feature, but likely not enough to matter in practice.