denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
98.21k stars 5.41k forks source link

package.json cannot resolve jsr dependencies from npm:vite inside workspace #24781

Open andykais opened 4 months ago

andykais commented 4 months ago

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

failed to load config from /home/andrew/Code/development/forager/packages/web/vite.config.ts
error when starting dev server:
TypeError: npm package '@jsr/andykais__ts-rpc' does not exist.
    at file:///home/andrew/Code/development/forager/packages/web/vite.config.ts.timestamp-1722216203693-cbe5226eadf6e.mjs:2:27
    at async loadConfigFromBundledFile (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:66365:15)
    at async loadConfigFromFile (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:66206:24)
    at async resolveConfig (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:65816:24)
    at async _createServer (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/chunks/dep-mCdpKltl.js:62432:18)
    at async CAC.<anonymous> (file:///home/andrew/.cache/deno/npm/registry.npmjs.org/vite/5.3.5/dist/node/cli.js:735:20)

Where the simple top level deno.json might look like so:

{
  "workspace": [
    "./packages/web"
  ]
}

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

dsherret commented 4 months ago

The .npmrc file is only discovered beside the workspace root deno.json file. You might need to move it there.

andykais commented 4 months ago

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

dsherret commented 4 months ago

@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 ....

andykais commented 4 months ago

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

andykais commented 4 months ago

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

andykais commented 3 months ago

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.
andykais commented 2 months ago

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