Issue
If you use multiple dependencies that reference each other (e.g. via peerDependency in npm), you'll likely run into issues as multiple versions of the dependency may be pulled in.
This is very common, such as when using npm:react and npm:lucide-react together with different versions pinned. You may see React get imported twice (such as version 18.2 and 18.3), which causes errors like the following:
Uncaught Error: Objects are not valid as a React child (found: object with keys {$$typeof, type, key, ref, props}). If you meant to render a collection of children, use an array instead.Workarounds
There are currently 2 workarounds which should resolve most cases:
1. Use esm.sh with ?external=a,b,c flag
https://esm.sh is a package repository that works great with Deno. It supports overriding dependencies with your local import map by using ?external=react.
This effectively works around the issue, in this example you could use imports:
{
"react": "https://esm.sh/react@18.2",
"lucide-react": "https://esm.sh/lucide-react?external=react"
}Or, if you'd like to use npm: you can use it for isolated dependencies:
{
"react": "npm:react@18.2",
"lucide-react": "https://esm.sh/lucide-react?external=react"
}2. Change dependency versions to resolve mismatches
The issue arises as npm:lucide-react@0.474 depends on react@^18 (meaning, the latest version of react which is >=18.0 and <19.0).
As of time of writing this is react@18.3.1 you can simply make sure you're using react@18.3.1 rather than an older or newer version.
You should preferably make your react version react@^18 instead of react@18.3.1 in this instance, since this may break later on as dependencies are updated unless you use the exact same version pin.
Long-term fix
The proper fix I believe is upstream in esbuild_deno_loader.
esbuild_deno_loader resolves using deno info independently on each dependency which may be the root cause:
There are a few related issues I've found:
It could also be supported by adding an ?external flag to npm: imports in https://github.com/denoland/deno_npm.
Since there are okay workarounds for the time being, and some demand on the upstream repos to fix, this isn't a current priority for this project to fix. However, if there's more demand or cases where the workarounds fail I can look into fixing.
Issue
If you use multiple dependencies that reference each other (e.g. via
peerDependencyin npm), you'll likely run into issues as multiple versions of the dependency may be pulled in.This is very common, such as when using
npm:reactandnpm:lucide-reacttogether with different versions pinned. You may see React get imported twice (such as version18.2and18.3), which causes errors like the following:Uncaught Error: Objects are not valid as a React child (found: object with keys {$$typeof, type, key, ref, props}). If you meant to render a collection of children, use an array instead.Workarounds
There are currently 2 workarounds which should resolve most cases:
1. Use
esm.shwith?external=a,b,cflaghttps://esm.sh is a package repository that works great with Deno. It supports overriding dependencies with your local import map by using
?external=react.This effectively works around the issue, in this example you could use imports:
{ "react": "https://esm.sh/react@18.2", "lucide-react": "https://esm.sh/lucide-react?external=react" }Or, if you'd like to use
npm:you can use it for isolated dependencies:{ "react": "npm:react@18.2", "lucide-react": "https://esm.sh/lucide-react?external=react" }2. Change dependency versions to resolve mismatches
The issue arises as
npm:lucide-react@0.474depends onreact@^18(meaning, the latest version of react which is >=18.0 and <19.0).As of time of writing this is
react@18.3.1you can simply make sure you're usingreact@18.3.1rather than an older or newer version.You should preferably make your react version
react@^18instead ofreact@18.3.1in this instance, since this may break later on as dependencies are updated unless you use the exact same version pin.Long-term fix
The proper fix I believe is upstream in
esbuild_deno_loader.esbuild_deno_loaderresolves usingdeno infoindependently on each dependency which may be the root cause:There are a few related issues I've found:
deno installwith incorrect peer dependencies installs incompatible React versions denoland/deno#26841It could also be supported by adding an
?externalflag tonpm:imports in https://github.com/denoland/deno_npm.Since there are okay workarounds for the time being, and some demand on the upstream repos to fix, this isn't a current priority for this project to fix. However, if there's more demand or cases where the workarounds fail I can look into fixing.