Relative Import Path of package dependencies throw error on build

[tspears1]

Version

2.4.3

Platform

OSX

What steps will reproduce the bug?

I'm using the radix-ui library for building a React client-side app on my site with esbuild to compile. I've tried adding these packages with ESM and NPM and in both cases, if the package has dependencies lume-loader throws an error like the following for @radix-ui/react-dialog:

deno:file:///Users/user/Library/Caches/deno/npm/registry.npmjs.org/@radix-ui/react-dialog/1.1.4/dist/index.mjs:16:29:ERROR: [plugin: lume-loader] Relative import path "react-remove-scroll" not prefixed with / or ./ or ../ and not in import map from "https://deno.land/x/lume@v2.4.3/plugins/esbuild.ts"

I even have those particularly directories ignored by LUME however it seems they're still being processed. I've gotten around it a few times by adding the package dependency to the import map, but its a tedious process and not always successful. Any suggestions?

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

Libraries to be imported without conflict.

What do you see instead?

Loading config file file:///Users/user/Sites/project/_config.js
✘ [ERROR] Relative import path "react-remove-scroll" not prefixed with / or ./ or ../ and not in import map from "https://deno.land/x/lume@v2.4.3/plugins/esbuild.ts" [plugin lume-loader]

    deno:file:///Users/user/Library/Caches/deno/npm/registry.npmjs.org/@radix-ui/react-dialog/1.1.4/dist/index.mjs:16:29:
      16 │ import { RemoveScroll } from "react-remove-scroll";

Additional information

No response

[oscarotero]

Yes, this is due a bug (or a behavior change, I don't know) of Deno.
I've reported to them here but didn't get any response yet: denoland/deno#27436

I'll try to find another way to resolve npm dependencies in Deno.
Meanwhile, can you try importing the package from esm.sh?

import radix from "https://esm.sh/radix-ui";

[tspears1]

That's very helpful to know! I'll keep an eye on that thread. (and thanks for the quick reply)

SO with ESM, if I mark it as external ("@radix-ui/react-dialog": "https://esm.sh/v135/*@radix-ui/react-dialog@1.1.4",), I get the same issue as with NPM.

If I dont mark it as external I keep getting errors like Cannot read properties of null (reading 'useState') which seems to be coming from a conflict of different version of React being used. (though for the life of me I can't tell where. everything is using React 18.3.1 yet React 19 keeps popping up in my deno.lock file.)

[oscarotero]

I suspect this bug won't be fixed anytime soon, because they didn't respond in 3 weeks.

I've trying to fix the plugin using the import_map package instead of relying on Deno's import.meta.resolve() function.

This has the benefit of defining a custom import map for the esbuild, independent of the deno.json file.

Can you try it now? It's available in the latest development version of Lume. You can upgrade it with deno task lume upgrade --dev.

If it doesn't work and you have a public repo with your code, I can take a look.

[tspears1]

@oscarotero - I think that solved it, at least for ESM imports. (Still running into some issues with React conflicting, but I think those are probably ME problems lol and nothing to do with Lume.)

There may still be an issue with npm when getting subfolders though. With esm you can solve it with a second import map entry. So for import ReactDOMServer from "react-dom/server" you need the following.

"react-dom": "https://esm.sh/react-dom@18.3.1",
"react-dom/": "https://esm.sh/react-dom@18.3.1/",

Which if you use the ESM CLI, it actually adds both automatically.
If you try to do that with the npm, you run into the same problem still.

[tspears1]

If you want to take a look you can see the repo here: https://github.com/tspears1/projects.bu.edu
I just pushed a new branch update-lume with the new dev version.

[oscarotero]

Ok, I've commited new changes to Lume (you can run deno task lume upgrade --dev again, to fetch the latest version).

• npm specifiers don't need to add the trailing slash. Only http specifiers need that. For example this works:

  "react-dom": "npm:react-dom@18.3.1"
  

  (no need to add "react-dom/")
• Now, changing all dependencies to npm makes the build to work and there are no errors. I have the following:

  "@radix-ui": "npm:@radix-ui@1.0.1",
   "@radix-ui/react-dialog": "npm:@radix-ui/react-dialog@1.1.4",
   "@radix-ui/react-dropdown-menu": "npm:@radix-ui/react-dropdown-menu@2.1.4",
   "@radix-ui/react-separator": "npm:@radix-ui/react-separator@1.1.1",
   "@radix-ui/react-slot": "npm:@radix-ui/react-slot@1.1.1",
   "@radix-ui/react-tooltip": "npm:@radix-ui/react-tooltip@1.1.6",
   "classnames": "npm:classnames@2.5.1",
   "react-dom": "npm:react-dom@18.3.1",
   "react-inlinesvg": "npm:react-inlinesvg@4.1.5",
   "react": "npm:react@18.3.1"

• But the app doesn't work (there are errors in the browser). Some components work fine, others not. Maybe the error is caused by some dependency that is not correctly bundled by esm.sh. I don't know.
• Note that esm accept some configuration. For example, you can configure the dependencies of some packages, and this could fix errors like having different react versions.
• I can't help more at this point. If you discover the dependency that is causing the error and there is something that I can do in Lume, please let me know.

[tspears1]

Thanks @oscarotero - this is all extremely helpful and I can take it from here.
The fix works great for getting the build to work. I'll chip away at the React issue - I'll let you know if I find anything related to Lume.

Appreciate all your help - loving Lume and the Lume CMS!

[oscarotero]

I've been playing with your repo a bit more and discover that esm.sh mixes React 18 and 19.
It seems to be a bug on esm.sh and i've opened an issue here: esm-dev/esm.sh#994

Maybe this is why JS breaks in the browser.

[tspears1]

Ah! This is what I suspected but wasn't able to prove yet. Yeah I think that's right. React 19 keeps popping up in my deno.lock. Thanks for opening that ticket - I'll keep an eye out.

[oscarotero]

I'm closing this since Lume 3 uses the official deno loader dependency and it works great with npm packages.