Better JSR workflow

[hansSchall]

This also includes some chore work, like updating .gitignore (deno.lock should be checked in), adding deno fmt to the pre-commit task (deno task check) and configuring git to use LF line endings as deno fmt does. Additionally I replaced deps.ts with import maps, as they are now the recomended default.

The main CI workflow fixes this PR contains are:

• remove deno old version
• run on master changes, not on main changes
• use the official denoland/setup-deno action

[emrahcom]

Hi @hansSchall,

IIRC actions/checkout@v3 throws a warning message. actions/checkout@v4 may be better

[timonson]

Thank you @hansSchall , but I won't accept this PR because jsr is not compatible with browser.

[hansSchall]

Of course JSR is compatible with browsers, just install it via NPM compat layer (npx jsr add @zaubrik/djwt) and let the bundler of your choice do the rest (a bundler is required anyway bacause of the TypeScript).

Although deno.land/x is not recomended anymore (just see the warnings on https://deno.com/add_module), we could keep compatibility by just remapping the deno.land/x import to jsr: in deno.json import map which is unsupported on deno.land/x and therefore the import remains the same while the jsr version respects mapping and will link to the jsr version.

By the way, I cannot understand your concerns about browser comaptibility because currently djwt provides no simple way to include it in client side js. deno.land/x does not support being imported directly (TypeScript), nor using a bundler because most ones will keep the https:// imports by default as they are most commonly used with CDNs. To use this aproach the user would have to manually exclude the respective URLs in the advanced bundler config. Additionally all of these approcaches would download all the files individually which results in a very bad performance. Not even copying the source code works because the same problems occur with the deno.land/std imports.

The most common way of distributing client side libraries is using NPM which would be supported with the NPM compat layer.

Actually the reason why I discovered the NPM/JSR threads was because I tried to use djwt client side.

PS: There are various attempts to bring native JSR support to (client side) bundlers (esbuild: https://jsr.io/@luca/esbuild-deno-loader (I have already used this, this is the official replacement for deno bundle), Vite: https://jsr.io/@deno-plc/vite-plugin-deno (This is my project))

[timonson]

@hansSchall you can import it with the browser via: https://github.com/Zaubrik/djwt/blob/master/dist/mod.js

I only work with ES modules.

[hansSchall]

The removed mod.js has nothing to do with JSR, I deleted mod.js in my PR because it is documented nowhere and deno bundle is deprecated so I thought it was outdated.

Despite its deprecation deno bundle has no problems with jsr, it emits exactly the same code.

If you want to continue support for a direct js bundle, we could simply set up esbuild. This is required as of Deno 2.0 anyway, because deno bundle will be removed.

import * as esbuild from "npm:esbuild@0.20.2";
import { denoPlugins } from "jsr:@luca/esbuild-deno-loader@^0.10.3";
import { encodeBase64 } from "jsr:@std/encoding@0.224.0/base64";

await esbuild.build({
    plugins: [...denoPlugins({
        importMapURL: `data:text/plain;base64,${encodeBase64(JSON.stringify({
            imports: JSON.parse(await Deno.readTextFile("./deno.json")).imports,
        }))}`
    })],
    entryPoints: ["./mod.ts"],
    outfile: "./dist/mod.js",
    bundle: true,
    format: "esm",
});

esbuild.stop();

[hansSchall]

Am I right that apart from JSR there is currently no way to include djwt with types in a TypeScript frontend project? How would you do that?