First-class JSR support

JSR packages can publish TypeScript source directly, rather than the usual npm model of shipping transpiled JS alongside .d.ts files.

It feels like that could be a really good fit for scriptc. Given something like:

import { something } from "jsr:@scope/package";

could scriptc resolve the package's TypeScript source and include it in the same compilation/type-checking graph as the application code?

My assumption is that, provided the package only uses constructs supported by scriptc's static tier, this could allow the dependency itself to be compiled to native code rather than requiring the dynamic runtime. It would also make JSR a potentially interesting ecosystem for libraries intentionally written to remain statically compilable.

I'm mainly curious whether this is something you've thought about, and whether there are architectural reasons why resolving JSR/TypeScript dependencies this way wouldn't work.

I realize npm compatibility is probably the more immediately useful target given the size of that ecosystem, but first-class JSR support seems like it could complement that nicely, especially for people interested in building mostly or entirely static scriptc applications.

The issue names no files, tests, or entry points to begin with. First clarify the intended JSR resolution behavior and architectural constraints, then identify the compiler and dependency-resolution areas that would need changes. Done would require an agreed implementation scope and validation that TypeScript JSR dependencies can enter the same compilation and type-checking graph.