[core] improve dynamic import in lib/mod.ts

[deer]

    start: async () => {
      if (Deno.args.includes("dev")) {
        const { default: dev } = await import("$fresh/dev.ts");
        return dev(Deno.mainModule, "./netzo.ts", config);
      } else {
        return start((await import("@/fresh.gen.ts")).default, config);
      }
    }

In #84 I commented out the import, since it's breaking type checking. I think you need to come up with a new way to do this. I guess the intent is to use this in client projects, where @/ is defined in the import map, but what you currently have throws errors for developers developing netzo.

[miguelrk]

Interesting, I thought the type errors during development where caused by the limited support of Deno LSP for monorepos, because types do work when outside of the monorepo setup... I'll see how to fix this, since this still requires that users set a @/ alias, and although we could encourage that, it shouldn't be required. We went this route instead of having the users pass an import.meta.url reference to the Netzo() entrypoint function.

That being said, and in spirit of our recent discussions @deer, it might be best to return to the default fresh project structure with a dev.ts, main.ts and a netzo.config.ts (extends the regular fresh.config.ts). We actually had it this way before, but we abstracted it away into a single netzo.ts for developer convenience (simpler project structure) and greater control (e.g. enforcing certain plugins). Going back to a netzo.config.ts would align netzo more with fresh, without sacrificing much DX:

1) split

import { auth } from "netzo/core/auth/mod.ts"
import { api } from "netzo/core/api/mod.ts"
export default defineConfig({
  plugins: [
    auth({...}),
    api({...}),
  ]
});

2) split but import from barrel file for DX convenience

import * as netzo from "netzo/core/mod.ts"
export default defineConfig({
  plugins: [
    netzo.auth({...}),
    netzo.api({...}),
  ]
});

3) unified

import * as netzo from "netzo/core/mod.ts"
export default defineConfig({
  plugins: [
    netzo({
      auth: {...},
      api: {...},
    })
  ]
});

Anyways, thinking about it, simplifying the project structure should ideally be done at fresh-land. I know the fresh.gen.ts file is also planned for removal. What do you think?

Update: created #92 to track this

[deer]

On the monorepo front, I guess the issues to watch are:

• Allow using different deno configs for different dirs denoland/vscode_deno#787
• LSP can't resolve import_maps in workspaces when using --unstable-workspaces denoland/deno#21769

But I think this is a slightly different issue. The solution here might be to convert away from a statically-analyzable dynamic import, and instead bury it behind a variable:

        const importLocation = "@/fresh.gen.ts";
        return start((await import(importLocation)).default, config);

The issue here is not that this file should be governed by a different deno.json(c), but rather that it's impossible for this import to ever resolve in the netzo framework repo, since there's no fresh.gen.ts anywhere.

The above change will at least keep the type checker happy, since it no longer tries to look for the import at the nonexistent @/fresh.gen.ts. But when run, it still works fine.

[miguelrk]

Reopening since I was forced to revert (70f9aa3, patch release 0.4.24) this back to the original

return start((await import("@/fresh.gen.ts")).default, config);

since this fix was throwing deploytime issue

The deployment failed: UNCAUGHT_EXCEPTION TypeError: module not found: 'file:///src/fresh.gen.ts' at async Object.start (https://deno.land/x/netzo@0.4.21/core/mod.ts:113:23)

For reference, the following attempts did resolve the type error, but threw the same deploytime error:

const importLocation = "@/fresh.gen.ts";
return start((await import(importLocation)).default, config);

const url = new URL("./fresh.gen.ts", Deno.mainModule);
return start((await import(url.href)).default, config);

const manifestURL = import.meta.resolve("@/fresh.gen.ts");
return start((await import(manifestURL)).default, config);

This type issue should be solved in a way that does not break deployments. This makes me wonder if going back to a plugin-first approach by mounting netzo as a normal fresh plugin and re-introducing netzo.config.ts and keep the original dev.ts and main.ts entrypoints of fresh would be better. An easier workaround is to simply pass the statically imported freshConfig object to the Netzo() entrypoint function...

[deer]

Hi @miguelrk, sorry about that. Can you provide more details on what deployment is? It works just fine on my laptop, so it'd be great to learn more about this environment in order to properly fix this.

[miguelrk]

Sure! This happens when running netzo deploy, which basically does a POST /projects/{projectId}/deployments with the project assets to the Deno Subhosting API (including obviously the fresh.gen.ts file). The Subhosting runtime has its intricacies, but its 95% that of Deno Deploy, which also very closely resembles the Deno CLI as you know. I suspect it has to do with Subhosting's resolution of dynamic imports, we know it takes the import map into consideration (since @/ works) but it makes me wonder why my other attempts above did not work.

The unfortunate thing for this issue is that it's more cumbersome to test, since it requires to make changes, create a new release (that's why I created several path releases earlier today 😆), and redeploying.