search

Zaubrik / djwt

Create and verify JSON Web Tokens (JWT) with Deno or the browser.
MIT License
228 stars 23 forks source link

Publish to JSR #85

Closed emrahcom closed 3 months ago

emrahcom commented 3 months ago

This PR adds a Github workflow to publish to JSR.

Assumed that the scope will be @zaubrik/djwt on JSR registry. Please update it (in deno.json) if it will be something else and update the version as 3.0.2 after the initial test.

To complete the task, @zaubrik/djwt should be created on jsr.io and linked to this repository.

hansSchall commented 3 months ago

I would love this and as far as i can see, djwt only depends on base64url from deno std, so it should be possible to use this even in browser.

timonson commented 3 months ago

Thank you @emrahcom

timonson commented 3 months ago

@emrahcom something went wrong with CI. Would you mind taking a look into it?

https://github.com/Zaubrik/djwt/actions/runs/10150942921/job/28069171066

error: Import 'https://registry-staging.deno.com/@std/encoding/meta.json' failed: error sending request for url (https://registry-staging.deno.com/@std/encoding/meta.json): error trying to connect: dns error: failed to lookup address information: nodename nor servname provided, or not known at file:///Users/runner/work/djwt/djwt/deps.ts:4:8

hansSchall commented 3 months ago

This is my default JSR CI workflow (might help): https://github.com/deno-plc/slip/blob/main/.github/workflows/jsr.yml

A few weeks ago I have built a JSR plugin for Vite and from that work I know that the JSR package resolution never fetches anything from registry-staging.deno.com, if the was jsr.io it would fetch all published versions, which is the first step when resolving imports. It looks like the problem is the old deno version (1.37.2), maybe in those days JSR was experimental and fetched from another domain that is shut down now.

By the way, I understand why the CI checks stable and canary, but why old and why OS matrix, djwt does not rely on anything patform dependent