deno
deno copied to clipboard
denoland
Support npm packages with git dependencies
On Arch Linux using the Arch Communty Repository deno, after upgrading to canary (which seems to be already done for the package) it does not work when i try to import npm:[email protected], instead it errors with:
error: npm package: [email protected]
Caused by:
0: error parsing version requirement for dependency: http-signature@git+https://[email protected]
om/wmurphyrd/node-http-signature.git#9c02eeb
1: Invalid npm version requirement. Unexpected character.
git+https://[email protected]/wmurphyrd/node-http-signature.git
~
2: Unexpected character.
git+https://[email protected]/wmurphyrd/node-http-signature.git
~
, so I searched some issue addressing this and found #18101 that says it should work, but, at least for me, it doesn't.
That's a slightly different issue. For that issue it was when the package.json existed in the current working directory and wasn't used. In this case, the dependency http-signature of activitypub-express has a git dependency, which is not supported at the moment.
So, while this feature is still not supported, is there any way to use the library?
Not at the moment because git dependencies are not supported/implemented. If they remove the git dependency and depend on npm instead then it might work:
https://github.com/immers-space/activitypub-express/blob/364d90705731dca755f3cb21747274eba0aad1e4/package.json#L35
We're also hitting this error. I get that github dependencies aren't supported, but the tough part is that this is an uncatchable, unrecoverable error:
try {
const pl = await import("npm:@postlight/parser");
} catch (e) {
// Never runs
console.error(e);
}
Even if the import() is in a Worker, as it is in our system, it's not possible to recover from this issue. In the meantime, while github dependencies aren't supported, can import() at least always try and throw a recoverable error?
I ran into this issue too, but got around it by using esm.sh. (esm.sh supports git dependencies since v116.)
I am experiencing the same problem, and esm.sh doesn't seem to solve it, as it returns a 500 on https://esm.sh/v119/[email protected]/deno/turndown.mjs (although this could be a temporary error).
Reconsidering this, I think it's a little more general: Deno throws an unrecoverable error for failed dynamic imports. I can't 100% confirm whether there's specified behavior here, but I can confirm that in Chrome, you get a TypeError for any failed dynamic import. It seems like the latter - a recoverable TypeError - is a lot better.
Digging in more, it seems like Deno actually preloads all dynamic imports, so if there's a failed dynamic import, it'll fail on module initialization, rather than when it's called. For example:
// This throws, even though the import doesn't run.
if (false) {
const pl = await import("npm:@postlight/parser");
}
Seems like this is https://github.com/denoland/deno/issues/17802
Where would we start to get to fixing this issue? Non-recoverable hard crashes because of sub-dependencies are a pretty hard problem for my application: we can't recover from them, and we can't easily detect when we're going to hit them. The expectation going in is that import() is recoverable, like it is in browsers, and Deno's doing something quite different here.
@tmcw there is now a PR for that here: https://github.com/denoland/deno/pull/24170
@dsherret and @lucacasonato #24170 was merged on 06/11/2024 but the issue still persists. Has it not been rolled out into a release?
@und-miller I can't reproduce #17802, which #24170 fixes. Can you open a new issue with a reproduction?
@dsherret, I did but it was closed. I authored #26274, which currently fails for me.
That's a different issue than https://github.com/denoland/deno/issues/17802
Would it be possible to get an update on this? Will this make it into any upcoming releases?
No update. It's challenging because we need to figure out the security story for it and probably need to add another flag (something like --allow-npm-git=github.com/some-org/some-repo).
