@developit let me know your thoughts on this, if you would prefer keeping this JS only then I can release something on DefinitelyTyped.

I'll do some cleanup and add some docs and JSDoc etc if this is likely to get merge :)

Nice! This looks great.

I might take a crack at a JS + JSDoc + checkJs version of what you have here just to compare, since it seems like most of the typing ends up being for the outward-facing API.

I might take a crack at a JS + JSDoc + checkJs version of what you have here just to compare, since it seems like most of the typing ends up being for the outward-facing API.

My master branch does a similar thing with just .d.ts files no JSDoc yet, but exposes the typings, I did that while I was figuring out how to type JSX :) https://github.com/AndrewLeedham/vhtml/tree/master/src

I might take a crack at a JS + JSDoc + checkJs version of what you have here just to compare, since it seems like most of the typing ends up being for the outward-facing API.

Considering this package has no external dependencies, if a conversion to typescript is done, rather than just js + jsdoc, then this package could use https://github.com/bevry/make-deno-edition to make itself compatible with deno (make-deno-edition publishes a edition-deno directory, with things like './empty-tags' changed to './empty-tags.ts' — this directory would be used directly by deno packages) and would set the deno field in package.json to the edition-deno/vhtml.ts file, with this field used when make-deno-edition is run on dependents of this package.

I might take a crack at a JS + JSDoc + checkJs version of what you have here just to compare, since it seems like most of the typing ends up being for the outward-facing API.

@developit did you want me to update my master branch to use checkJs?

@balupton Nice! Up to Jason if he wants to support it :)

Editions incurs a substantial install and exec cost, I don't think it's something worth doing for a library that just has two sources.

@AndrewLeedham I'll take a look at your master to compare. Sounds like we have a similar preferred setup, haha.

Editions incurs a substantial install and exec cost, I don't think it's something worth doing for a library that just has two sources.

The make-deno-edition workflow does not use the editions autoloader, so no consumer exec cost: deno consumers would load vhtml via http://unpkg.com/vhtml/edition-deno/vhtml.ts. The development exec cost to generate the edition is about a second. For install, we are talking about a few extra files.

@balupton interesting, I didn't know Deno had built-in support for that. Do you know if it's just a static lookup for edition-deno, or are they actually respecting the rules present in package.json? Seems like in the case of this library it would be possible to just statically point to src/vhtml.ts were it to be landed as TS.

@balupton interesting, I didn't know Deno had built-in support for that. Do you know if it's just a static lookup for edition-deno, or are they actually respecting the rules present in package.json? Seems like in the case of this library it would be possible to just statically point to src/vhtml.ts were it to be landed as TS.

I'll clarify this in more detail to come over the coming period, with tutorials and videos, however the quick version is:

Deno only supports already resolved paths (e.g. ./other.ts), be it relative or absolute (e.g. https://unpkg.com/badges@^4.13.0/edition-deno/index.ts)

This means that, anything imported into Deno must be directly resolvable and uses ESM. Which means that Deno has no conception of package.json. For imported TypeScript, that means each import must not omit or occlude the .ts extension.

What bevry/make-deno-edition does however, is go through your source edition (the directory containing your package's typescript source files), and resolves them all:

1. internal imports (e.g. relative path to another file inside your source edition) are mapped to their typescript file
2. remote imports (e.g. any URL) are assumed to be compatible, as node.js doesn't support them, so it is assumed they are already deno compatible)
3. dependency imports (e.g. any package you install into node_modules) are checked to see if they have a deno field in their package.json denoting where to look for the deno compatible entry, or if their main field in the package.json ends with .ts then it is assumed to be deno compatible
4. so the more dependencies that make-deno-edition is run on, the more dependents can become compatible with deno
5. bultin imports (e.g. fs) are mapped to their corresponding deno polyfill

With this, make-deno-edition then makes a directory called edition-deno that has the deno compatible resolutions applied for paths that were successful; if a source file is not compatible, it is ignored if it is optional, or cause the deno edition to fail if it is required.

Inside the README.md you then instruct the consumers of your package to point to the unpkg cdn url for the deno edition and its entry, for this package it would become https://unpkg.com/vhtml/edition-deno/vhtml.ts.

Users of this package who are writing native deno code, can then use that URL directly, or they can just write node, browser, and deno comaptible code by letting make-deno-edition handle the deno compatibility.

That is the essentials.

This can be taken and automated further, with utilities like bevry/projectz to automate the README.md instructions, and bevry/boundation to automate the entire package management and compatibility; for instance using all of these, allows the package start-of-week to have a custom entry for browsers, node, and deno - with everything else automated, the readme, including the installation instructions, which includes the deno instructions which directs the user to https://unpkg.com/start-of-week@2.7.0/edition-deno/deno.ts, the package.json, etc etc.

So the most important thing for now, is for make-deno-edition to be run on the ecosystem primitives (packages that have no dependencies) so that the ecosystem can then build ontop of them, with ever increasing compatibility.

@developit Any thoughts on the rewrite vs allowJS approaches?

Is there any updates on this? Any help needed?

Not really sure, just looking for some guidance from @developit on the approach.