Closed josh-hemphill closed 6 days ago
Although just realized putting jsr.json
in src
is probably not good and wouldn't include the README, explicit include
is probably the way to go and cross my fingers it doesn't care about the tsconfig
(Running another dry-run looks like it doesn't care about the tsconfig. 🥳)
@josh-hemphill this sounds like a great idea! I would be happy to merge a PR implementing this.
Last night I was trying to get a one-liner in the scripts to update the jsr.json
version, but I learned after much trial and error I can't use the json
CLI to do that. I hate having to add a script file that's only going to be a few lines, but will probably just do that so I can get the PR uploaded.
Is your feature request related to a problem? Please describe. I've been consuming packages from it in all my one-off scripts because I can just throw a
import a from "jsr:package@1"
in my files and just get a best-effort updated version short of major breaking changes. Buteta
isn't there, so I thought I'd ask.Describe the solution you'd like Reading through the docs for JSR and skimming the
eta
codebase, I think it could be published to JSR just by putting ajsr.json
file in thesrc
directory, to skip everything else, and assuming there are no esm-incompatible statements in the codebase, it should "just work"Describe alternatives you've considered I can keep using
https://deno.land/x/eta
but Deno is prioritizing JSR and encouraging not usinghttps
in imports since it prevents optimizations.I'm happy to make a PR, I think I almost have one already, just got to figure out the best way to update the version in
jsr.json
on release in thenp
scripts. Already ran a dry run and it all seems to work (it does want two explicit return types and two explicit types add on the public api surface to speed up type-checking for enabling auto-.d.ts generation, but it's not strictly necessary, just have to add another flag.