Separate the concepts of "unwrapping" and "resolving"

[iwoplaza]

We recently outlined and partially implemented the root.unwrap(resource) API. Its purpose was to peer underneath TypeGPU and get access to the underlying WebGPU resource associated with that TypeGPU resource.

Examples:

• root.unwrap(resource: TgpuBuffer<AnyTgpuData>): GPUBuffer
• root.unwrap(resource: TgpuBindGroupLayout): GPUBindGroupLayout
• root.unwrap(resource: TgpuBindGroup): GPUBindGroup

When we want to also add the functionality to turn typed functions into the code they represent, along with all their dependencies, .unwrap seemed like the ideal candidate. This however posed some problems:

• root.unwrap returns a string, not a WebGPU resource. We could return a shader module instead, but that limits its usability in migration workflows.
• TypeGPU does not use these strings underneath, so conceptually, the API would not do the same thing as it does for other resources.

Proposed solution

const shaderCode = tgpu.resolve(fooFn);
// or
const shaderCodeWithExternals = tgpu.resolve(shaderCode, { utilityFn, FooStruct });

[reczkok]

Makes sense 👍 Passing everything to root.unwrap seems convenient but comes with some limitations that could become a hinderance.