BOLL•2mo ago

Deno workspaces and Fresh, a viable combination?

Hello! I'm attempting to port an existing project to Deno and Fresh. I'm still working on the initial setup, and I have a structure like this:

/
├── deno.json
├── server/
│     ├── deno.json
│     └── a Fresh installation
└── lib/
      ├── deno.json
      └── old code to be ported

/
├── deno.json
├── server/
│     ├── deno.json
│     └── a Fresh installation
└── lib/
      ├── deno.json
      └── old code to be ported

I want to separate the code to port and the Fresh installation as one will be ripped apart and the other should already be functional, and figured I could use workspace to join everything up, but I'm struggling to get it to work. First off, the workspace for lib cannot have a name, as there is not one file but a range of files to reference. Do I need to create an index.ts file in there to reference to make this work at all? I already have a generator for that so should be possible but it'll be a large one. I want this so I can reference the stuff in there without the eventual ../../../lib/###. If I remove the name from the subfolder deno.json, the error for missing a file goes away, but instead I get this error from the Fresh installation:

error: Relative import path "preact" not prefixed with / or ./ or ../ and not in import map from "https://esm.sh/v135/preact-render-to-string@6.3.1/X-ZS8q/denonext/preact-render-to-string.mjs"
    at https://esm.sh/v135/preact-render-to-string@6.3.1/X-ZS8q/denonext/preact-render-to-string.mjs:2:46

error: Relative import path "preact" not prefixed with / or ./ or ../ and not in import map from "https://esm.sh/v135/preact-render-to-string@6.3.1/X-ZS8q/denonext/preact-render-to-string.mjs"
    at https://esm.sh/v135/preact-render-to-string@6.3.1/X-ZS8q/denonext/preact-render-to-string.mjs:2:46

Is using workspaces with Fresh even a reasonable approach at this point in time, or should I try to move the Fresh deno.json to my root folder and run it all from there? I mostly want it there so scripts can be executed from the root of the project, but maybe that is just wishful thinking. Thinking about it now it feels like I should just leave the deno.json in the ./server folder, hopefully the compile settings will still apply to the other folders for the language server even if they are a level outside. There's many things I'm unsure of here, but figured I could leave a post here with my musings, I'll be back tomorrow 😅 This is so I can sleep after having spent many hours trying to make sense of Fresh today, sadly I'm not that fresh myself so it's been slow going!

1 Reply

BOLLOP•2mo ago

Been experimenting with workspaces now. Some observations: 1. When using an alias, like: @scope/myfunc it turns out at least in WebStorm, there is no reference to the source file anymore, it becomes a local reference that cannot be followed outside of the current file, even if the code runs and gets the doc-comment. This makes aliases less useful. 2. The above is also true when the workspace export points to an index.ts file that re-exports the contents of that workspace. One of the main reasons I had to use workspaces was the alias feature, but due to this difference in how it works in the IDE I'll avoid using it. Is this up to JetBrains? Are they solely responsible for how the Deno plugin in their IDEs work, or is there a collaboration? Right, I should have tested this from the start, but it appears as if the deno.json inside the server folder still works with the code that resides outside that folder. Still not sure if all the compile options will be true for the language server when I edit stuff in the other folders, but I hope so. I'll mark this as solved as I doubt anyone will drop by with any other information 🤣 And I'll skip using workspaces entirely as the alias feature only makes things worse for now. Turns out I do need to have the deno.json file in the root after all, else my formatting is not applied, possibly compile settings as well, on folders outside the server subfolder.