[Integration API] Support dynamic content construction in injectTypes based on file destination URL

[sushichan044]

Body

Summary

This proposal suggests allowing the content passed to injectTypes() to be set dynamically by using the output path of the .d.ts file, which is the function's return value.

Please check the Example section to see what this makes possible.

docs of injectTypes(): https://docs.astro.build/en/reference/integrations-reference/#injecttypes-option

Background & Motivation

Currently, we cannot generate type definitions that depend on the path of the d.ts file output by injectTypes() in a single call.

As a workaround, it's possible to get the output directory of the .d.ts file with a first injectTypes() call and then use a second call to inject the path-dependent type definitions.
However, this is not ideal because it adds the extra type definitions from the first call to the user's type namespace.

My library uses this workaround to generate type definitions as follows:
https://github.com/sushichan044/astro-simple-feature-flags/blob/fe0b4a2cb245c1a13ad518b57b978494a229a980/packages/astro-simple-feature-flags/src/integration.ts#L42-L75

Goals

• Allow developers to inject type definitions that depend on the output path in a single injectTypes() call.

Example

I expect to be able to write code like this:

import { dirname, relative } from "node:path";
import { fileURLToPath } from "node:url";

injectTypes({
  content: (dest) => {
    const dtsRoot = dirname(fileURLToPath(dest));
    const pathToAstroConfig = relative(dtsRoot, "./astro.config.mjs");

    return [
      "declare module 'virtual:my-virtual-module' {",
      `  type AstroConfig = typeof import('${pathToAstroConfig}').default;`,
      "}",
    ].join("\n");
  },
  filename: "virtual.d.ts",
});

[florian-lefebvre]

You can already get the dir using the result of createCodegenDir() (in the config setup hook) IIRC

[sushichan044]

Yes, by using ‎createCodegenDir(), I was able to achieve the same thing as this proposal.
The content of this proposal would be nice to have, but it seems like it’s not strictly necessary.

[delucis]

Nice. Thanks @florian-lefebvre! Sounds like the use case is covered in this case and I imagine we most likely wouldn’t add a second API to do the same thing, so will close this.