Open andykais opened 4 months ago
The .npmrc
file is only discovered beside the workspace root deno.json file. You might need to move it there.
hmm I dont think that is the solution @dsherret. I tried moving .npmrc
to the top of the workspace (and tried copying it into both places) and I still get the same error
@andykais can you link to a repo that I can clone and run a set of steps to reproduce the behaviour?
Ex. 1. Clone .... 2. Run deno run ....
sure thing. @dsherret I created a branch on the sample repo using workspaces that repros the issue with steps to run: https://github.com/andykais/sveltekit-deno/tree/workspace-repro. Let me know if there is other info I can provide
I will say one other oddity is that vite
appears to require package.json
to run correctly. This seems to be related to how it imports its vite.config.ts
file. I have attempted to set up import maps for all its dependencies in a deno.json file, but that doesnt seem to work nicely, especially since it doesnt seem to understand nested npm dependencies from an import map declaration. I dont want to side track this current discussion though, so I can create a separate issue for that topic
I will say one other oddity is that vite appears to require package.json to run correctly.
Just a small follow up that I discovered this is called out in the deno docs https://jsr.io/docs/with/vite, so at least the part about vite requiring package.json & node/npm to function in deno is expected.
The workspace + package.json issue does still persist in deno 1.46.1
, and attempting to use
DENO_FUTURE=1 deno install
gives a similar error output:
error: npm package '@jsr/andykais__ts-rpc' does not exist.
I just wanted to poke this issue again to share that this issue is adding a decent amount of extra steps and churn to my development workflow. I have a project structure like so:
monorepo/
deno.json
packages/
core/
deno.json (name: @forager/core)
cli/
deno.json (name: @forager/cli, depends on @forager/core and @forager/web)
web/
package.json (name: @forager/web, depends on @forager/core)
where monorepo/deno.json
is the workspace file, and web/package.json
needs special treatment because of the aforementioned bug. I am going to lay out what the standard workflow is right now for updating these different packages. If I update @forager/core
, generally I can then update @forager/cli
at the same time, and things function as expected. Then I just make two pushes to github bumping the version number on @forager/core
and then @forager/cli
. This all works very well. The issue comes in when I want to manage developing the @forager/web
package, which is in the 'middle' of the dependency tree and lives outside the deno workspace. There is no good mechanism to locally link workspace dependencies into @forager/web
, nor is there a good way to link dependencies out of @forager/web
to @forager/cli
. This means that every change is only testable by publishing a public version on jsr, then updating that dependency locally. Luckily, my libraries here are not popular 😅 so I can push broken/debugging versions all the time and prove those out. If this were a live library with real users though, this workflow would become problematic very quickly. It also just creats a lot of confusion on jsr seeing many different minor & patch versions on jsr when ideally I can just iterate on all of these things locally at the same time
Version: Deno 1.45.3
I am working on building a sveltekit project that can be developed in deno and ran in deno production. So far I have been able to get vite dev & vite build to work with a custom adapter. The code is here in a barebones example repo. The issue is that deno dependencies seem to behave differently inside a workspace.
If I take the linked repo above and drop it inside a workspace in another repo I get errors like this
Where the simple top level deno.json might look like so:
I suspect this is because deno is not treating the current directory like a "node project", since I can achieve a similar error by adding a deno.json file to the current directory