feat: CommonJS build

[pranav-growthx]

No description provided.

[dagnelies]

If I remember right, removing the "type": "module" will cause it to break server-side or browser-side as module import. I'm quite unsuire since I don't remember the details but I know it was very tricky to produce a module that could be imported by both browsers and server-side with platforms like cloudflare workers.

But I think vor the #49 "v2", I'll try a triple build:

• neutral modules like currently
• a node bundle as commonjs with only the server-side
• a browser bundle as global variable with only the client-side

[pranav-growthx]

Interesting. Do you have a reference to that PR?

That seems very weird. The reason I raised this as a DRAFT PR was cause I need to move the types into a commonplace instead of in ./esm

[pranav-growthx]

Also, do you have any planned timeframe for v2? I might make a package out of the fork for my use case till you get the release out

[dagnelies]

Interesting. Do you have a reference to that PR?

That seems very weird. The reason I raised this as a DRAFT PR was cause I need to move the types into a commonplace instead of in ./esm

Honestly, I have no clue, it was at the very beginning. At the time I needed the lib to work both for browsers and cloudflare workers and I remember spending many hours cursing at build tools to get a bundle working for both at the same time. I even wanted to make a small article out of it ...but as usual, time is scarce.

Also, do you have any planned timeframe for v2? I might make a package out of the fork for my use case till you get the release out

Dunno. It's not even that big of a deal actually. But time is even scarcer... Sorry, I can't give you a date.

[pranav-growthx]

Any specific reason you are using tsc and esbuild both for transpiling?

I see that the esm build and types is done by tsc, the bundle is done by esbuild.

esbuild should be able to handle builds entirely and tsc can then only export the types

[pranav-growthx]

Updated my previous code to delegate the entire build process to esbuild. tsc will only generate types now. Additionally, I have also pulled out types into its own folder inside dist

I have created my own package to test it out, which you will find here

If you want to test it out, your .npmrc will need

@pranav-growthx:registry=https://npm.pkg.github.com

[dagnelies]

Sorry to close your PR. Just to be on the cautious side, I'd like to postpone build changes to v2. Since there are plenty of people already using this lib as is, in production too, and the risk/benefit (as low as it might be) is not worth it IMHO. I already started working on v2 though in a dedicated branch. I'd also like to keep the build simple, and I'll be trying to it with just:

    "build": "npm run build-esm && npm run build-neutral && npm run build-node && npm run build-browser",
    "build-esm": "tsc",
    "build-neutral": "esbuild src/index.ts  --platform=neutral --bundle --sourcemap --minify --target=es2022 --outfile=dist/webauthn.min.js",
    "build-node":    "esbuild src/server.ts --platform=node    --bundle --outdir=dist/cjs",
    "build-browser": "esbuild src/client.ts --platform=browser --bundle --minify --sourcemap --outdir=dist/browser",

to provide a four-fold build:

• as normal modules (the default, usable by both client & server)
• the client side only, as browser global to import via script tag
• the server side only, as commonjs for old node environments
• as "bundled minimized modules". Mainly to be compatible with v1.x, and nice for browser demos showing how the server works.

I hope this will do the trick and I hope you can indulge me closing this PR to avoid any risks. Thanks nevertheless for the effort, I'll mention you once the v2 is ready if you want so that you can test out v2.

[pranav-growthx]

That works but I think the command that you have mentioned for node will output one single file.

[dagnelies]

Isn't that the usual way? That's actually what esbuild recommends by default (https://esbuild.github.io/getting-started/#bundling-for-node). Also, only the server side would be included that way.

[pranav-growthx]

Thats because esbuild is a bundler. Bundling here would mean that all your imports would be gone and server.js would be the only entrypoint into the code. If that is the expected behaviour then it works but if expectation is that I could import utils as well, then you will need to register it as a separate entrypoint