Publish to npm?

[saghul]

esbuild is written in go but since it relates to the JS ecosystem it's also published to npm. One can simply do npx esbuild and It Works (TM).

At some point in time I snatched the @quickjs-ng npm org, so we could do something like: npx @quickjs-ng/qjs and get the CLI or npx @quickjs-ng/qjsc to get the compiler.

Thoughts?

[bnoordhuis]

I thought this was going to be about publishing the wasm build!

No strong opinion. I don't think I'd use that myself but sure, go ahead.

[saghul]

There is already quickjs-emscripten which is more comprehensive IMHO.

I'll leave this open and think about it some more :-)

[ahaoboy]

There is already quickjs-emscripten which is more comprehensive IMHO.

I'll leave this open and think about it some more :-)

I've been trying to find a way to use C/Rust command line tools in JS recently. Although it's still in the early stages, there is a qjs example for testing.

This is more portable than wasm and napi.

https://github.com/ahaoboy/qjs-easy

[saghul]

This is very close to what I was thinking!

If you intend to maintain it I'd be happy to have a link to it in the documentation!

[ahaoboy]

This is very close to what I was thinking!

If you intend to maintain it I'd be happy to have a link to it in the documentation!

This is just an executable file that downloads the corresponding platform from github, and then forwards the cli parameters, so there is not much maintenance work. only need to modify the version every time quickjs-ng is released.

However, I can only release @easy-install/qjs instead of @quickjs-ng/qjs

https://github.com/easy-install/qjs

[saghul]

You can publish it under your org and update the docs to offer it as an option. Then we can see how it goes and condier moving it to this org. What do you think?

[ahaoboy]

You can publish it under your org and update the docs to offer it as an option. Then we can see how it goes and condier moving it to this org. What do you think?

Let's wait for some time while I do some testing and optimization and see if there is a better way.

[gengjiawen]

I thought this was going to be about publishing the wasm build!

wasm is too slow compared to native version.

Publish to npm

big +1

[guest271314]

GitHub owns NPM. 6 of one, half-dozen of the other. At least on GitHub the source code is right there, readable, and files are individually fetchable.

wasm is too slow compared to native version.

Depends on the input, what application is used to build the WASM file, and which optimizations are used. You can get different results depending on if AssemblyScript is used or WASI-SDK is used for WASM builds, and if wasm-opt, etc. are used.

Here's the same algorithm (Native Messaging hosts that accept 1 MB of input and echoes back the same 1 MB to the browser) written in different programming languages. nm_wasm is using Bytecode Alliance's Javy, which depends on QuickJS.

0	'nm_c'	0.11179999999701977
1	'nm_cpp'	0.11340000000596047
2	'nm_qjs'	0.1248999999910593
3	'nm_rust'	0.1445
4	'nm_wasm'	0.207
5	'nm_deno'	0.28679999999701977
6	'nm_typescript'	0.2883000000119209
7	'nm_bun'	0.31109999999403953
8	'nm_nodejs'	0.3583999999910593
9	'nm_python'	0.40170000000298023
10	'nm_spidermonkey'	0.5227999999970198
11	'nm_d8'	0.6506000000089407
12	'nm_llrt'	0.7142000000029802
13	'nm_tjs'	0.7592999999970198

[guest271314]

If you publish to NPM might as well publish to JSR. There's already esvu and jsvu.

]I don't have npx on my machine. I fetch the Node.js nightly archive, extract node, and get rid of the rest. E.g., essentially the same process I do at the commandline done in the browser https://github.com/guest271314/download-node-nightly-executable.

[guest271314]

If anything include an "upgrade" command, like deno and bun do.

deno upgrade canary
bun upgrade --canary

[saghul]

That's a much higher lift. Please stay on topic.

[guest271314]

That's a much higher lift. Please stay on topic.

I don't think so. deno upgrade in particular is very useful. On the commandline deno even notifies when a new commit happened and a canary version is available. Immediate fixes. With Node.js you have to download the entire archive=, much of which is not the node executable.

It's 2025. Some of Node.js ways of doing things is kind of archaic at this point. There's nothing special about NPM. If I have a choice between fetching sources from NPM and GitHub I choose GitHub. Fetching from NPM implies a node_modules folder, which we can do without altogether when using Deno, where network imports are possible.

But hey, if you want qjs to be on NPM just for the sake of being on NPM, have at it.

[guest271314]

Doesn't jsvu https://github.com/GoogleChromeLabs/jsvu and esvu https://github.com/devsnek/esvu suffice?

What would be useful in this repository is for the latest tag to point to the latest release version of QuickJS.

Something like we can do with Deno, Node,js has nightly, and Bun canary. Right now if somebody doesn't know the version of QuickJS NG they have to go to the release downloads page, or make two requests to get the current version.

We should be able to do this with qjs NG. Notice I don't have to write out a version.

wget --show-progress --progress=bar --output-document deno.zip https://dl.deno.land/canary/$(wget -qO- https://dl.deno.land/canary-latest.txt)/deno-x86_64-unknown-linux-gnu.zip && unzip deno.zip && rm deno.zip

wget --show-progress --progress=bar --output-document bun.zip https://github.com/oven-sh/bun/releases/download/canary/bun-linux-x64-baseline.zip && unzip bun.zip && rm bun.zip && mv bun-linux-x64-baseline/bun $PWD && rmdir bun-linux-x64-baseline

Right now I'm building QuickJS NG because there's no canary release I can just fetch from GitHub without knowing a version number.

[saghul]

I don't think so. deno upgrade in particular is very useful. On the commandline deno even notifies when a new commit happened and a canary version is available. Immediate fixes. With Node.js you have to download the entire archive=, much of which is not the node executable.

I know. What I said is that implementing that is non-trivial and out of the scope of this project.

What would be useful in this repository is for the latest tag to point to the latest release version of QuickJS.

That's already the case.

It's 2025. Some of Node.js ways of doing things is kind of archaic at this point. There's nothing special about NPM. If I have a choice between fetching sources from NPM and GitHub I choose GitHub. Fetching from NPM implies a node_modules folder, which we can do without altogether when using Deno, where network imports are possible.

But hey, if you want qjs to be on NPM just for the sake of being on NPM, have at it.

All I did is ask what the appetite was. You added your opinion. No need to repeat it several times.

Note that we already do binary releases on GH so this is not a replacement, just an addition, if we do decide to go for it.

Doesn't jsvu https://github.com/GoogleChromeLabs/jsvu and esvu https://github.com/devsnek/esvu suffice?

esvu currently downloads it from our GH releases and it will mostly suffice. I don't think either of them installs the compiler though.

Right now I'm building QuickJS NG because there's no canary release I can just fetch from GitHub without knowing a version number.

We don't do canary releases. If you want to download the latest release, GH doesn't make it very obvious, but here is how: https://github.com/quickjs-ng/quickjs/releases/latest/download/qjs-linux-x86_64