Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Deno can directly import in TS/JS from URLs, really nice for small 'shell scripts', but has some considerable downsides for bigger projects:

https://deno.com/blog/http-imports

PS: also Godbolt's C/C++ compilers can directly #include from URLs, I guess they run their own custom C preprocessor over the code before passing it on to the compilers:

https://www.godbolt.org/z/6aTKo4vbM

View on HN

> Deno can directly import in TS/JS from URLs

FWIW, that's a native JS feature (minus the TS part).

Yeah, not sure what Deno has to do with this, other than they implemented the standard at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Deno is the only server that has done so though. Neither node nor bun support them.

The HTTP imports astound me. Having little control over how bundlers fetch code randomly screams vulnerability vector. How people are okay with it is wild to me.

You're right, of course, but there's little practical difference from doing `npm install` unless you're actually auditing the supply chain. It just automates a step.

The difference is that you have a single file to audit with npm. With Deno, any file in your codebase might pull in a dependency.

That assumes someone is actually auditing the npm deps.

It’s trivial to audit your dependencies with https://socket.dev

Disclosure: I’m the founder.

Despite the ease of auditing services, there are notoriously a lot of devs using unaudited deps. Maybe they don't even think about it, unfortunately.

Which isn't really a problem for simple one-file 'shell scripts'. For bigger projects, Deno already suggested to maintain all external imports in a central file.

They should have at least have something like HTML Subresource Integrity[0], including a hash so at least changes to what comes back from the import hasn't changed.

[0] https://w3c.github.io/webappsec-subresource-integrity

Yes, though it's not enforced when it should be.

Reply on news.ycombinator.com