undefined | Better HN

0 pointsrevskill3y ago0 comments

Does it have guidance on publishing your own package to github ?

0 comments

4 comments · 1 top-level

katsura3y ago· 3 in thread

Not specifically for GitHub, but:

https://deno.land/manual@v1.30.3/advanced/publishing

The point seems to be that it doesn't need anything special, you just import files, and Deno takes care of the rest.

brundolf3y ago

As soon as Deno introduced me to the idea of just using URLs for importing dependencies, it immediately felt like obviously the best way

Want a private repository? Stand up an apache server. Or an S3 bucket. CDN in front? Sure, why not

Want to casually host and not deal with a repository? Import directly from github

Namespacing? Domain names. And they already have ownership controls/auth that your ecosystem doesn't then have to reinvent

Combine that with import-mapping (being able to tell the runtime to load X when it sees Y), and I don't see any reason to do it any other way

matklad3y ago

One potentially compelling reason is dependency resolution. You can’t express Cargo-style “collect _requirements_ for all dependencies, and then pick the minimal set of dependencies which satisfies all requirements” with just urls. You potentially can encode fancy constraints for each specific dep into an url, but you can’t have an algorithm which globally looks at the set of dependencies. If you want that use-case, you’ll need some extra tooling which reads constraints and writes the import map.

OTOH, it’s not clear if fancy constraints solve more problems than they create.

Notably, if the only constraint is `^x.y.z`, than the gready, expressible-via-urls algorithm of always selecting the latest semver-compatible version yields the minimal solution.

1 more reply

revskillOP3y ago

Yes, the only requirements/issues as i see, is:

- Need a fallback plan if original hosting died ?

- Need to specify immutable version/hash for the url ?

1 more reply

j / k navigate · click thread line to collapse

0 comments

4 comments · 1 top-level

katsura3y ago· 3 in thread

Not specifically for GitHub, but:

https://deno.land/manual@v1.30.3/advanced/publishing

The point seems to be that it doesn't need anything special, you just import files, and Deno takes care of the rest.

brundolf3y ago

As soon as Deno introduced me to the idea of just using URLs for importing dependencies, it immediately felt like obviously the best way

Want a private repository? Stand up an apache server. Or an S3 bucket. CDN in front? Sure, why not

Want to casually host and not deal with a repository? Import directly from github

Namespacing? Domain names. And they already have ownership controls/auth that your ecosystem doesn't then have to reinvent

Combine that with import-mapping (being able to tell the runtime to load X when it sees Y), and I don't see any reason to do it any other way

matklad3y ago

One potentially compelling reason is dependency resolution. You can’t express Cargo-style “collect _requirements_ for all dependencies, and then pick the minimal set of dependencies which satisfies all requirements” with just urls. You potentially can encode fancy constraints for each specific dep into an url, but you can’t have an algorithm which globally looks at the set of dependencies. If you want that use-case, you’ll need some extra tooling which reads constraints and writes the import map.

OTOH, it’s not clear if fancy constraints solve more problems than they create.

Notably, if the only constraint is `^x.y.z`, than the gready, expressible-via-urls algorithm of always selecting the latest semver-compatible version yields the minimal solution.

1 more reply

revskillOP3y ago

Yes, the only requirements/issues as i see, is:

- Need a fallback plan if original hosting died ?

- Need to specify immutable version/hash for the url ?

1 more reply

j / k navigate · click thread line to collapse