Chris Thomas

Ya, the module itself should be installing dependencies, and not the sdk. The sdk needs to be treated like any other npm dependency

I agree that the two options aren't quite mutually exclusive, but it is a bit of a balancing act. > I'm not sure being more flexible would impact the learning...

(Take this all with a grain of salt, since I haven't looked too deeply on how things are constructed internally) > We installed the SDK as a local dependency because...

The way that prisma does it (and there are other ways), is that it has its static library as `@prisma/client`. Internally it references `.prisma/client` which is the pre-generated code that...

Assumption Note: This comment assumes that the code for a generated module is only needed in the engine. Another thing that may work. Since you only really need the types...

First, thanks for the great write up. I'll go through this from top to bottom first, then have more freeform comments below. I also want to point out that I...

I just created https://github.com/dagger/dagger/issues/8722 for the issue where I can't run `dagger call` locally. This is mainly caused by the fact that there are two separate package managers at play...

> One of the reasons for decoupling is we want to be able to generate client bindings from dependencies in a dagger.json for running directly on the host, instead of...

The defaults are actually assigned before the constructor runs > Because instance fields of a class are added before the respective constructor runs, you can access the fields' values within...

Using `@func` for these fields still feels very odd, since they are written, and accessed like fields in Typescript. I do understand that they are treated like functions internally to...