[feature] Advertise when a package has an `npm:` dependency

[jeff-hykin]

I would like to get away from the legacy code of leftPad & friends. It'd be really nice if I could tell whether or not a jsr package had a npm dependency somewhere in its dependency tree.

I would love to be able to filter-search based on what's in the dependency tree of a package.

While "does it use npm:?" is my #1 concern, I would love having a slew of similar warnings:

• Warn about eval with dynamic strings
  • Note: Its okay if obfuscation "defeats" this warning (e.g. globalThis["e"+"val"]). Its still good for the community to know if a library is blatantly using eval.
  • While a warning for the package codebase is nice, even better would be a warning if ANYTHING in the dependency tree was blatantly using eval.
• Warn about node-gyp in dep tree
• Warn on non-esm code in dep tree
  • warn on "loose" imports (import "./a" instead of import "./a.js")
  • this is relevant for bundlers
• Warn for dynamic imports
• Advertise/warn certain impure Api usage (Deno.Command, Deno.dlopen, and equivalent node API's)
  • Often I ask something like: is jsr:blah/video-editor actually a video editor (wasm/js)? Or is it just an FFI wrapper to ffmpeg, or -- even worse -- is it just a child process wrapper around ffmpeg?
  • I don't care about complex "what if only uses child process if its macos and deno" stuff. A grep "Deno.Command" on the codebase would be better than nothing.
  • I'd also be fine/thrilled if this was somehow tied to the permission system, but I know its a lot harder to detect that.
• Advertise a "size" (ex: small, medium, large, massive)
  • based on total the size of the dependency tree
  • Not "just a number". Size isn't just number of dependnecies, or number of lines of JS, or number of different package authors, etc. Its kind of all of those things. I trust the deno team's judgment to define (and evolve) size definitions (based on any/all those metrics and more)
  • For an example, "tiny" could be "only depends on std"
• Warn for direct usage of node globals
  • global, process, Buffer, setImmediate , __dirname, __filename
• Warn on use of deprecated Deno API's

[KnorpelSenf]

Perhaps this should simply affect the score, rather than being a separate independent warning?

[jeff-hykin]

Its not that a package is worse just for using eval, or npm, its just that I want to know which ones do and which ones don't. Contrast this with something like, not having documentation. No docs/types just means the package is worse than it could be.

There's probably an argument to be made that deprecated API's, sloppy imports, and/or direct use of node globals should decrease the score. I'd be fine with that.

But for eval, npm:, the size of the dep tree, etc I don't think these warnings/advertisements should affect the score.

[BlackAsLight]

I don't understand how calculating the size would work. But I do think that uploaded code being obfuscated or minimised should be labelled as such.