[Tistron]

Wouldn't you just include a file by it's minor version like this:

  import * as E from 'https://cdn.jsdelivr.net/npm/fp-ts@2.5/lib/Either.js';

Whenever you `--reload` you'll get the latest 2.5.x release, no?

This should work out recursively for all the deps if they follow the same pattern, no?

[Tistron]

This seems to be what is suggested as per https://dev.to/pika/introducing-pika-cdn-deno-p8b that was posted by somebody else.

[jakear]

I wasn't aware of the semver URL scheme, but it just brings more problems.

At this point they've just replaced `npm` with `pika` and expect people to think it's an improvement to not have a centralized file containing package dependencies and the last resolved versions of packages. Criticisms:

1. Updating dependencies becomes much more of a diff (every file that uses it needs to be updated). The alternative solution to this is creating a single `packages.ts` file that imports all the external deps, and all your modules import from there. Which just `npm` with more steps.

2. No lock file. I saw them present this at tsConf and I believe the original idea was that this wasn't needed because the URLs are the lock, but as you point out in practice people use URL's that aren't unique identifiers. This means no way to guarantee that all developers or even users of the project have the same dependency state. This will be a massive pain for debugging and maintaining packages. (Edit: see below, you can lock deps (unclear exactly how) - but only if you pay them!)

Looking at the Pika home page, they tell me I can build and release without a bundler.... so you're telling me that they expect people to put out production software that downloads it's dependencies at runtime and thus:

- Is unstable because if they use the semver-URL scheme you mentioned and a patch version comes out that breaks the website, all users are instantly broken instead of the internal build being broken.

- Is unstable because if a dependency/host goes offline, all users are broken instead of an internal build being broken (think leftpad but much worse as your users are instantly impacted, likely before you even know about it)

- Is insecure because if a host is malicious, they can choose to supply different packages for a small subset of the requests, such as those coming from govt. requests against political targets, hosted build machines, etc. and nobody will have any way of knowing because there's no lock file/integrity hashes.

I further see on the Pika CDN page that they share packages across websites. This is seems to be a massive security flaw, as websites are able to modify these packages and now those modifications will apply to all websites using the package. It's prototype pollution-as a-feature!

Oh, and at the bottom of the page:

> Want to get more out of Pika CDN? The CDN will always be free, but you can also access paid, production features like:

> Granular Semver Matching & Version Pinning

> ...

So base features that are the core of working with npm/yarn/any modern package manager are a paid feature in Pika.

I'll pass.

[animalCrax0rz]

That's mostly unintended FUD (but still FUD) or problems that can be worked around:

<< - Is unstable because if a dependency/host goes offline, all users are broken instead of an internal build being broken (think leftpad but much worse as your users are instantly impacted, likely before you even know about it) >>

So you don't recall Leftpad?

<< - Is insecure because if a host is malicious, they can choose to supply different packages for a small subset of the requests, such as those coming from govt. requests against political targets, hosted build machines, etc. and nobody will have any way of knowing because there's no lock file/integrity hashes. >>

Are you kidding me?

https://www.zdnet.com/article/microsoft-spots-malicious-npm-...

[Tistron]

Pika is just some website serving js. deno is including a bundle command that will create a single script that contains all your deps that can be version controlled and/or distributed. also, even without bundling deno doesn't download imports every time it is run. It downloads imports when you first run it or when you ask it to --reload. Seems quite similar to npm in that regard, except for the lockfile perhaps.

They are also working to support importmaps which could become part of this story.

In any case, competent and smart people are working to make it usable. It is still a work in progress but I love the direction they are taking. It will be great to be able to run safe javascript where I provide it with the permissions it gets.