Fix typescript blueprints

[runic horizon]

I have this PR with a fix in the typescript SDK introspection https://github.com/dagger/dagger/pull/11018
a bit about blueprints here https://deploy-preview-11013--devel-docs-dagger-io.netlify.app/getting-started/quickstarts/blueprint

Basically in typescript, and only typescript, introspection fails because its looking for the "main" module name and not the blueprint module's name (error snippet in PR)

Chatting with @desert sun , i'm confused how this works fine in go and python without sdk modification. If I create a go module that doesn't have an object matching the module's name, it fails, but no issues with blueprints

and I think with this fix, that expected error case of missing an object that matches the module name would no longer be an error in typescript, which is not intended. I will add a test for this

[desert sun]

I have an idea

The error "main object not found..." comes from https://github.com/dagger/dagger/blob/aaa13befbe949553e6f0f3deb1b03ff5be2f34ec/cmd/dagger/module_inspect.go#L338

So it's common to all SDKs

But on Typescript I already do the check

What we could do in typescript is:

• Check for the main object (easier to then introspect)
• If no main object: loop through all classes and consider each class as main to make sure we explore everything

In case of regular module, the CLI side error will create a failure but in case of blueprint, the objects will be there

[runic horizon]

ah ok so like right here https://github.com/dagger/dagger/blob/49d08e62f325fcefd518c20e2bd90c58f2b18bd8/sdk/typescript/src/module/introspector/dagger_module/module.ts#L127
instead of breaking, i'd move the introspection logic from below into the loop

[desert sun]

Yeah exactly

So like instead of

    const mainDaggerObject = new DaggerObject(mainObjectNode.node, this.ast)

    this.objects[this.name] = mainDaggerObject
    this.references[this.name] = {
      kind: TypeDefKind.ObjectKind,
      name: this.name,
    }

    this.resolveReferences(mainDaggerObject.getReferences())
    this.propagateReferences()

You would loop through all class, and call the exact same logic

I would suggest to add the loop no matter the case, but just create a 1 item array if the mainObject is found

So you can simply create a new private method that either look for the main object or return all classes instead

As ResolvedNodeWithSymbol<T>[]

Them boom loop over it and here we go it's fixed

Make sure to update typescripts tests since we verify that it errors out if the main object isn't found

I let you do it so you can gain knowledge on the TS sdk but feel free to ping if you have any issue 😄

[runic horizon]

Awesome thank you, i will work on those changes!

[worldly heron]

Thanks for doing this @runic horizon and sorry for not catching this pretty major gap in the feature 😅

[runic horizon]

no problem lol it broke in a surprising way but I added more tests!

[runic horizon]

how would you go about setting the description? yolo?

const mainFileContent = mainObjectNode.file.getFullText()
this.description = this.getDescription(mainFileContent)

yolo would be do this 👆 if (!this.description)

[desert sun]

Hmm

Yeah no description I think, because it's only for cloud

[runic horizon]

got it that makes sense. it should only apply to blueprints

[desert sun]

Yeah exactly

[runic horizon]

so it wouldn't apply here

[runic horizon]

all green @desert sun https://github.com/dagger/dagger/pull/11018
the findAllDeclarations function kind of bothers me because its 99% the same as findResolvedNodeByName but even moving the main logic out to a new function will result in more code than it is now 🤷‍♂️

[desert sun]

I’ll review that tomorrow!

It’s okay to have duplication if the code is simple to read 🙂

[worldly heron]

Fix typescript blueprints