Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert to TypeScript #26

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AndrewLeedham
Copy link

I followed the way https://github.com/developit/mitt is setup.

This is likely a breaking change as minified:main": "dist/vhtml.min.js" no longer exists.

Some notes about the changes:

fixes: #25, #19

@AndrewLeedham
Copy link
Author

@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 :)

@developit
Copy link
Owner

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.

@AndrewLeedham
Copy link
Author

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

@balupton
Copy link

balupton commented Jun 19, 2020

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.

@AndrewLeedham
Copy link
Author

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 :)

@developit
Copy link
Owner

developit commented Jun 19, 2020

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.

@balupton
Copy link

balupton commented Jun 19, 2020

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.

@developit
Copy link
Owner

@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
Copy link

balupton commented Jun 21, 2020

@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/[email protected]/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.

@AndrewLeedham
Copy link
Author

@developit Any thoughts on the rewrite vs allowJS approaches?

@brkn
Copy link

brkn commented Sep 18, 2020

Is there any updates on this? Any help needed?

@AndrewLeedham
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Thoughts on TypeScript support?
4 participants