Export browser for Deno / Fresh & JSR

[hapaxlife]

Hi,

Thanks for your library :-)

You have export server & type for Deno. Could you do the same for browser in order to user it in Fresh ?

Do you plan to put it also on jsr ?

Thanks

[MasterKale]

Hello @hapaxlife, can you help refresh my memory what Fresh is?

As for JSR support, I'm intrigued but haven't sat down to figure out what it might take to migrate things from Deno + dnt for server and types. It also remains to be seen if JSR will see wide adoption.

I see that JSR is becoming a first-class package repo in Deno 1.42, so that's progress. And I know it's possible to add JSR as a package repo for Node. I'd say JSR is a strong contender for the next place I aim to start deploying SimpleWebAuthn to.

Yours is the first voice asking for deployments to alternative package repos than NPM and https://deno.land/x, but more people may chime in later. For now I'm content to wait and see how things play out.

[hapaxlife]

Thanks for your answer

Fresh is a full stack modern web framework for JavaScript and TypeScript developers. It is based on Deno and developped by Deno team.

It is a SSR with a concept of island for shipping javascript into page. For the client auth page, I import in my SSR Fresh the browser library (the origin of my initial demand). The server renders the page with the browser javascript code that is shipped to the client.
https://fresh.deno.dev/docs/concepts/islands

The fact that browser is not exported in Deno is not blocking. We have just different ways of import in the code.

[jpaoad31]

Hello @MasterKale,

I am chiming in because I am running into the same issue with writing client-side code in deno. I'm still very new to web development, so my apologies if anything I'm adding here is a little uninformed.

I am using Fresh in a web application and noticed there is no importable browser.ts available on Deno.land/x/simplewebauthn. Seems like an easy fix from my perspective, just include another "convenience import" file. If it is possible I would appreciate being able to use an import from Deno.land rather than having to rely on npm for this package.

Also while looking into this I noticed there are missing file extensions on imports throughout the entire SimpleWebAuthn/packages/browser/src directory. It prevents me from being able to import SimpleWebAuthn/packages/browser/src/index.ts directly into Deno without issues for missing import files. It seems like you added files extensions everywhere in the server source code in commit dc29a40 so the lack of file extensions here appears to be a potential mistake or oversight.

[MasterKale]

I never targeted @simplewebauthn/browser for inclusion in 1) Deno projects that 2) leverage SSR. I can see how the structure of the browser package makes it difficult to use in such projects, though.

I'll have to think on this. I don't build the browser lib like I do server and types so I need to figure out how to write browser like Deno code (i.e. with .ts extensions in imports, etc... while still being able to build to single-file UMD and for NPM. I use dnt for building server and types, I wonder if it can work with Rollup 🤔

[MasterKale]

Hello @hapaxlife, @jpaoad31, @robvanvolt, and @sachaw, I'm pinging you all in here because you've all expressed varying degrees of interest in using SimpleWebAuthn in your Deno projects. I've been experimenting with hosting this project over on JSR.io in PR #634. I'm happy to report that I have "v11.0.0-alpha2" releases of browser, server, and types published over there:

https://jsr.io/@simplewebauthn

Can I ask for your help in putting these libraries through their paces? I'm fairly confident that deno add jsr:@simplewebauthn/server and deno add jsr:@simplewebauthn/types should work fine based on some of my own preliminary testing, but I'd love to hear about your experiences using these libraries as hosted through JSR.

deno add jsr:@simplewebauthn/browser should also be feasible, but I only published it just now and need to learn how to spin up a Fresh project to test it out with SSR myself. While I'm making time for that, those of you with active Fresh projects may be able to have some fun.

And heck, if you're so inclined, I'm also curious about your experiences using npx jsr add in any Node, Bun, and Cloudflare Worker projects you might be responsible for, or might spin up to test out.

JSR is tentatively a really cool way to host stuff, but I don't want to make it onerous for users to pull into their projects if I missed anything while experimenting with replacing the current deno.land/x hosting with JSR, if not also NPM hosting 🤔

[sachaw]

One big thing for using JSR is uncompiled source distribution and automatic compilation for node/bun users.

[hapaxlife]

Hi,

Thank for trying to put your project on JSR. It works for my project (after migration to v11 😊 ). I have just switch from "npm" to "jsr" in my deno.jsonc file

   - "@simplewebauthn/browser": "npm:@simplewebauthn/[email protected]",
   + "@simplewebauthn/browser": "jsr:@simplewebauthn/[email protected]",

[MasterKale]

Hey all, would it be acceptable to stop supporting import of these packages from deno.land/x and only support installation via deno add jsr:@simplewebauthn/browser/etc...? If I stop referencing third-party packages in SimpleWebAuthn via https://... specifiers (so I'm using normal-looking import ... from 'somePackage' within my libraries) because JSR doesn't support https://... modules, then importing SimpleWebAuthn like from https://deno.land/x/[email protected]/deno/browser.ts raises errors:

error: Relative import path "@hexagon/base64" not prefixed with / or ./ or ../ and not in import map from "https://deno.land/x/[email protected]/packages/server/src/helpers/iso/isoBase64URL.ts"
    at https://deno.land/x/[email protected]/packages/server/src/helpers/iso/isoBase64URL.ts:1:20

I can't see how I can support deno.land/x and JSR with the same codebase because of this fundamental restriction on packages that get hosted on JSR. deno add jsr:@simplewebauthn/... and deno add npm:@simplewebauthn/... are supported from Deno v1.46+ so perhaps it's not a big deal to say, "only installation from JSR and NPM in Deno projects is supported."

[MasterKale]

I'm going to drop deno.land/x hosting support. Deno's package hosting migration guidance is a little ambiguous but it definitely seems like it's "either JSR or deno.land/x" because of that restriction on using HTTPS module paths in JSR packages:

https://jsr.io/docs/migrate-x-to-jsr

I was going to release everything as "v12" anyway, but until now I didn't really have a reason to call it a major version release. "No longer support deno.land/x use" is a decent reason to increment the major version number.

[MasterKale]

cc @spendres

[MasterKale]

Progress report: I'm running some final tests on the big refactor I've been working on. Preliminary results are looking good, for example here's @simplewebauthn/browser running in a Deno Fresh project, installing "v11.0.0-alpha3" of the library from both JSR and deno.land/x:

islands/WebAuthnJSR.tsx
Run deno add jsr:@simplewebauthn/[email protected] jsr:@simplewebauthn/[email protected] then:

import { browserSupportsWebAuthn, bufferToBase64URLString } from '@simplewebauthn/browser';
import { AuthenticatorAttachment } from '@simplewebauthn/types';

export default function WebAuthn() {
  const supportsWebAuthn = browserSupportsWebAuthn();
  const attachment: AuthenticatorAttachment = 'platform';

  return (
    <div class="py-6 items-center">
      <h1>@simplewebauthn/browser (JSR)</h1>
      <h2>WebAuthn supported?</h2>
      <h3>{`${supportsWebAuthn} (Client)`}</h3>
      <p>bufferToBase64URLString: {bufferToBase64URLString(new Uint8Array([0, 0, 0, 0]))}</p>
      <p>attachment: {attachment}</p>
    </div>
  );
}

islands/WebAuthnDenoLand.tsx
Specifying an https://deno.land/x/... path to the library:

import { browserSupportsWebAuthn, bufferToBase64URLString } from "https://deno.land/x/[email protected]/deno/browser.ts";
import { AuthenticatorAttachment } from 'https://deno.land/x/[email protected]/deno/types.ts';

export default function WebAuthn() {
  const supportsWebAuthn = browserSupportsWebAuthn();
  const attachment: AuthenticatorAttachment = 'cross-platform';

  return (
    <div class="py-6 items-center">
      <h1>@simplewebauthn/browser (deno.land/x)</h1>
      <h2>WebAuthn supported?</h2>
      <h3>{`${supportsWebAuthn} (Client)`}</h3>
      <p>bufferToBase64URLString: {bufferToBase64URLString(new Uint8Array([0, 0, 0, 0]))}</p>
      <p>attachment: {attachment}</p>
    </div>
  );
}

EDIT: Importing from deno.land/x doesn't work anymore since I'm using import maps in @simplewebauthn/browser and @simplewebauthn/server...see #542 (reply in thread)

Things are looking up...

[spendres]

I don't see a problem relying on jsr and dropping denoland. But, you could use deno.json import maps to transform your urls to names that vibe with jsr.

[spendres]

Oh, then you will have to abandon deno.land/x to support jsr.

[MasterKale]

Hello all, SimpleWebAuthn v12.0.0 marks the beginning of official support for installation of all three packages from JSR as well as from NPM 🚀

See here for full release notes:

https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v12.0.0

[spendres]

Thank you, @MasterKale, for your unwavering effort to update this library.