[animalCrax0rz]

This brought up in my mind the thought that while Deno is still WIP (for example, packaging of Rust plugins is not yet resolved) and the ecosystem around it barely exists it was designed to have no dependency on 3rd party tools like npm and yarn.

[jakear]

It also provides none of the benefits of npm/yarn. In my understanding it’s as if every package you used pinned all of their deps.

[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.

[animalCrax0rz]

I think there's some confusion here.

NPM is both a massive repository as well as a package manager.

Deno will (soon?) have a package manager, but it won't be tied to one central repository run by a private company, now part of a massive corporation (Microsoft.)

So let's not lump package manager and repository: you can have a package manager that pulls in all the exact or latest dependencies at build time, but it does not have to be tied to one central repository owned and administered by one company.

Centralize-able yet decentralized.

[jakear]

Npm is the exact same. You can have your local npm talk with a registry other than the npmjs one. It’s as simple as a `registry=` line in .npmrc.

So this problem it’s pretending to solve isn’t actually a problem. And the solution introduces more problems (see comment on sibiling)

[animalCrax0rz]

It's not about choosing a different registry for all your modules, which will almost always be a commercial for-profit entity due to the cost of running and maintaining a centralized repository of that scale. AFAIK, or as far as I can envision, it's about a future where we can have the repository be a decentralized graph. It's definitely more challenging but we won't be dependent on one or few companies to host all modules. What do you think of that idea? My point is Ryan was right to avoid recreating dependence on commercial for-profit entities.

[tracker1]

I'm a bit mixed... that said, it's only a small step apart from what rust does for packages...

I would like to see a package repo for deno, if only to ease publishing/finding modules.

[okareaman]

The Deno team recently blessed Pika

https://dev.to/pika/introducing-pika-cdn-deno-p8b

[PudgePacket]

That's quite strong wording, nothing in that article indicates that Deno is blessing Pika specifically.

In fact Ryan Dahl said one of their biggest regrets was blessing npm in node. I'd be surprised if Deno jumped into blessing a package registry any time soon.

[okareaman]

Could be too strong. I couldn't find the email, post or discourse discussion where I got that impression