Preview the transpiled build so I can verify runtime compat with CI before publishing

[bradenmacdonald]

For packages that are pure ESM+TypeScript, it's currently easy to run the test suite using Deno with CI, e.g. using GitHub actions to run deno test. I found that it's also relatively easy to write a script to convert the tests to Bun format and run the tests under Bun, to ensure that any changes I'm making to the package will work with Bun.

But... I'd also like to have automated tests that my package works with Node.js and perhaps browsers too, before I publish the new version to JSR. But that requires getting the transpiled version of the build, which is currently only available after I publish the module to JSR.

Once dnt supports JSR, I could use DNT to transpile the code and run the test suite, which would be great. But from the fact that DNT doesn't currently support JSR, I assume that this is actually a different build process than what JSR uses. And ideally I'd like to test with a browser engine in CI too, not just Node.js.

(I tried using ts-node in the meantime but it has some major bugs with ESM code under certain node versions, and wasn't working for me.)

So: would it be possible in the future to have some way to get the transpiled build that JSR would produce, so I can run tests against it (compatibility tests on different runtimes), before I publish it? Or if this is currently possible, could you document how to do so in the example GitHub Actions publishing workflow docs?

(Even better in the long term would be the ability to write a short "smoke test" script, and have either GitHub Actions or JSR itself automatically run that script on each runtime as part of the publish workflow, as a way of verifying the runtime compat automatically)

[kitsonk]

I want to add my support for something like this. I have had to basically resort to publishing pre-release versions to JSR to be able to test compatibility with Bun, Cloudflare Works and Node.js. It is a really awkward DX and a lot of friction.

[marvinhagemeister]

Wondering if we should add a way to locally generate the npm tarball similar to npm pack. All other package managers support directly installing a tarball afaik.

[kitsonk]

That certainly would help and a starting point.

Long term, totally loved the low friction of dnt that allowed me to run my test suite under Node.js. I could do all my development locally. For something like oak, the workflow now is publishing pre-release tags on JSR and then having 3 different "test" projects with Node.js, Bun and Cloudflare Workers and effectively running a simple "smoke test" to see if I didn't break anything obvious. It is far from where I was with dnt and able to run my whole test suite against the code with a simple deno task build.

[jollytoad]

I've resorted to running a local JSR so I can preview my package and get everything into shape before publishing to public. This isn't ideal though, as it's not that trivial to get it running - it requires adding entries to /etc/host, starting three separate services, including a rust build, and publishing std lib and any other deps into it (and each package need manual approval).

It would be nice to run a bare minimum JSR service locally (even if just a docker container) that could be published to, where package versions can be updated and deleted, and the API proxies to the public JSR to save having to add deps such as std lib ... this could also be the basis for a private registry too.

[jollytoad]

Here's another idea: how about pre-publishing to JSR, so it's not public, allowing you to check everything is ok, test it etc, and then click a btn and/or hit an API to make it live, or to ditch it? these could be time-limited, so they are automatically ditched after a fixed, eg. 24 hrs. Avoiding unnecessary accumulation of cruft.