@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 noJSDoc 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 usehttps://github.com/bevry/make-deno-edition to make itself compatible with deno (make-deno-edition publishes aedition-deno directory, with things like'./empty-tags' changed to'./empty-tags.ts' — this directory would be used directly by deno packages) and would set thedeno field inpackage.json to theedition-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 usecheckJs?

@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 viahttp://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 foredition-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 tosrc/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 foredition-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 tosrc/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 ofpackage.json. For imported TypeScript, that means each import must not omit or occlude the.ts extension.

Whatbevry/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 adeno field in theirpackage.json denoting where to look for the deno compatible entry, or if theirmain field in thepackage.json ends with.ts then it is assumed to be deno compatible
4. so the more dependencies thatmake-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 callededition-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 theREADME.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 becomehttps://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 lettingmake-deno-edition handle the deno compatibility.

That is the essentials.

This can be taken and automated further, with utilities likebevry/projectz to automate the README.md instructions, andbevry/boundation to automate the entire package management and compatibility; for instance using all of these, allows the packagestart-of-week to have a custom entry forbrowsers,node, anddeno - with everything else automated, the readme, including theinstallation instructions, which includes thedeno instructions which directs the user tohttps://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 formake-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.