Ways to automatically discover Deno ports about denoify HOT 12 CLOSED

It shouldn't break anything. If it dose please report. Best regards

from denoify.

@KillyMXI You are right, it's fixed in 1.0.1

from denoify.

Hi @KillyMXI,

Thank you for pointing out this crucial issue.
I don't know if you are aware but Denoify does a lot for auto detecting available deno ports and do so without requiring any particular action from the module author.

You can try and add as dependency evt, tsafe run-exclusive or minimal-polyfill to the package.json of a given project and try running denoify. You'll see that Denoify automatically resolves the deno.land/x version of evt, tsafe run-exclusive and minimal-polyfill and it matches the exact version.

Take EVT for example, you can see that it depends on minimal-polyfill and run-exclusive. Now if you look at the code transpiled for deno and see that it has been resolved to the deno port in the correct version.
It works even if a module hasn't been published on deno.land/x.
To accomplish that denoify uses oktokit and look in the repo for something resembling a deno distribution.

If we fail to find a deno dist hosted on the repo denoify then looks if we have a custom replacer for the module in question.
With custom replacer we can perform complex transformations on the import statements but it must be done on a case-by-case basis and it's not exactly straightforward. Look at the replacer we need for "react-dom".

In last resort we look at known-port.json.

You can look at the code here.

If you have any idea to improve the process and help us reach the critical mass, I am all ears.

The problem is that not enough module maintainer are interested in supporting deno. Look at this pr that I opened for fp-ts. The diff was like 2 lines and it didn't get merged...

from denoify.

Oh. Looks like it was premature for me to come up with suggestions based merely on theoretical experience. Glad it does more.

But I think it also exposes the issue with documentation. The example repo just provides some examples but gives no overall picture. Understanding the algorithm would be more useful. And referring to own client packages only makes sense as examples of good practices.

Although I'm not sold on some practices. In particular, I wouldn't accept a PR with "like 2 lines" as linked above. Mainly because for me having a deno_dist folder in the repo seems less evil (for a simple package at least) than a CI script I barely understand. I don't want to be in charge of maintaining that. I would rather wait for a GitHub Action with a clean API.

Any other improvements would probably be above my understanding. In particular, I'd be pretty unhappy to rely on a custom replacer but it will require a good familiarity with existing cases to identify patterns and try bringing a solution into the base package.

from denoify.

But I think it also exposes the issue with documentation.

Yeah, that's true 😞

Understanding the algorithm would be more useful.

The problem is that:

1. It is very sophisticated, it's description would have to be a long text that I know very few people would read, if any.
2. If I update the algorithm I have to update the documentation accordingly. Just keeping the demo repo up to date is easier.

HOWEVER: Long story short the algo serches for the repo url in the package.json that sits in the node_modules/ directory and it looks for a mod.ts or a deno_xxxx/ directory on the latest tagged branch.

Although I'm not sold on some practices. In particular, I wouldn't accept a PR with "like 2 lines" as linked above.

I didn't see it under this angle. I now understand better why it wasn't merged.

There is always the possibility of using a custom a custom .deno.ts module for things that can't easily be ported...

How sucessfull where you denoifying node-html-to-text so far?

from denoify.

It is very sophisticated, it's description would have to be a long text that I know very few people would read, if any.

I got an impression it misses the forest behind the trees currently. Like, I see all those special cases in the README and it seems like this is it, there are no more generally applicable rules. And it wasn't particularly easy read anyway.

Listing (declaring) the artifacts the algorithm is looking for rather than reproducing the algorithm in plain English would be a reasonable approach.

In particular, I don't plan to have a mod.ts file and I don't like deno_dist folder name. I'll check through the list to make sure there are other artifacts that will make my Deno port discoverable.

How sucessfull where you denoifying node-html-to-text so far?

Haven't thought about it yet. That would be a long way.
Currently working on new packages that will become it's dependencies or otherwise related and I figured there is something good to make available in Deno land. I will probably also rework some other packages to get rid of some dependencies and make them Deno-friendly. But there are still many things to address about node-html-to-text itself.

from denoify.

I got an impression it misses the forest behind the trees currently. Like, I see all those special cases in the README and it seems like this is it, there are no more generally applicable rules. And it wasn't particularly easy read anyway.

I am sorry you had a bad experience reading the documentation.
To some it up, a module is discoverable by denoify if:

• Only if it's repo field in package.json points to a public GitHub rep,
• The algorithm will look for a deno distributions source files on the latest tag or on the default branch.
• It will look for a mod.ts file at the root. Then if it doesn't find one,
• (TODO) It will read the denoify.out and denoify.index field from the package.json, if they aren't any.
• It reads the compilerOption.outDir or compilerOption.declarationDir (TODO) field from the tsconfig.json and look for a deno_xxx directory (usually deno_dist)

from denoify.

I now have a couple of my deno packages public and it seems denoify can't automatically find them:
https://github.com/mxxii/leac
https://github.com/mxxii/peberminta

Checking denoify.out should solve that.

I'm not sure at what point denoify.index is used. If it points inside the source dir (that's what I see in the example repo) then I suppose I only need to care about it when running denoify in the upsteam package. It would require some clarification if something is inferred from that in the client package.

I'm glad denoify is able to figure out a separate export (entry point) of peberminta package once the port link is provided manually.

I'm still concerned about the ability to find deno.land/x/ link rather than github link. I don't mind to fill another field in package.json if it can't be found by other means.

from denoify.

Thank you for the update.
I think about working on this everyday but I am a bit overwhelm at the moment.
I will come back to it as soon as I can.

from denoify.

Hi @KillyMXI,
I finally dealt with this issue.
Now, if you upgrade denoify to v0.15 and release a new version of leac and peberminta they will be automaticallty discoverable.

Meaning that this import:

import { createLexer } from "leac";

Will be tranpiled into:

import { createLexer } from "https://raw.githubusercontent.com/mxxii/leac/v0.5.2/deno/mod.ts";

I created a documentation page: https://docs.denoify.land/automatic-discovery-of-ports

from denoify.

Thank you.

I hope this doesn't break the discoverability of the second entry point of peberminta.
At least it keeps working with new denoify version and existing explicit ports.
Will check again when I publish new versions.

from denoify.

I found a difference:
If I still have ports specified in my package.json, denoify uses it's own resolution algorithm anyway.
It would make sense to treat my input with higher priority and let me override paths.

from denoify.