Dynamic file imports inside JSR packages not working

[davideperozzi]

I'm currently trying to migrate to JSR with deno 2.0. My package has dynamic imports like:

await import('file://' + file);

And after I published my package to JSR and tried to run it locally after installing it globally, I got this error:

TypeError: Module not found "https://jsr.io/{..pathToFile}"

It somehow tries to import it from JSR, despite having it marked as a local import. I don't know if this is a bug or expected behavior? I assume you can't dynamically import from a package installed from JSR? Seems limited to me. Might have to move away from deno as I don't want to reverse all my changes.

Anyone has a smiliar issue and figured it out? Would appreciate the help!

[grenierdev]

I'm having the same issue with https://jsr.io/@baseless/client/0.3.0-rc.11/cli.ts.

deno run -A client/cli.ts ../app/src/app.ts -d works.
deno run -A jsr:@baseless/client@0.3.0-rc.11/bls ../src/src/app.ts -d don't.

I tried @std/path/resolve, import.meta.resolve, forcing file:// as you did.

I understand the security aspect of not allowing importing modules at runtime, but it's exactly what I'm trying to do. Like Tanstack Router, I want to run a command to load a module and extract stuff from the module.

This use-case is legit.

[davideperozzi]

@grenierdev Yeah, security is a big issue with this. A dependency could just import random files without the user even knowing it. Maybe this could be solved through an extra flag? Or make the user somehow aware of what files will be imported by which module. Since this works with "deno.land modules", I expected it to work with JSR as well.

[emmalineautumn]

This is such a bizarre limitation. I can understand preventing the import of http or even other package manager modules, but for local dynamic imports? Hope we can get eyes on this because this is a severe limitation that applies exclusively to JSR. At least a flag like you've suggested would allow us to acknowledge the risk and move on.

[ignwombat]

This limitation makes my idea of a CLI significantly more tedious. My only idea so far on how to make it easy, is to make the CLI callable, where you have to pass a helper function to import FOR it.

[ignwombat]

I managed to get a workaround to this issue by creating a sort of "import helper" function that you would pass to your package.
Your package would then use this helper function as a replacement to import

import someTool from 'jsr:@example/sometool@0.1.0';

someTool({
    importHelper: path => import(path)
});

[ignwombat]

I used this idea to make a very unorthodox CLI:

1. The CLI is called like any other
2. CLI created a helper.ts file which calls the library, while passing an import helper
3. CLI performs deno run on the helper file

[ignwombat]

I used this idea to make a very unorthodox CLI:

Also managed to use deno eval --ext=ts and passed the contents of such helper file, which eliminates the need to write to a file. Although this is significantly more insecure, due to eval having access to everything.

Example:

import packageInfo from './deno.json' with { type: 'json' };

// import.meta.main is true if the .ts file was directly called using 'deno run'
if (import.meta.main) {
    const helperContent = `import { myTool } from 'jsr:@example/my-tool@${packageInfo.version}';
await myTool()`;

    const command = new Deno.Command('deno', {
        args: ['eval', '--ext=ts', helperContent],
        stdin: 'inherit',
        stdout: 'inherit',
        stderr: 'inherit'
    });

    command.spawn();
}

export const myTool = async () => {
    console.log('Hello world');
}