script-able types for better future

[loynoir]

Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

• script-able types

• types provider

• types of network import

• types of json module

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

{
    "typesProvider": "@typesgen/providerImportId"
}

📃 Motivating Example

• hard code types of per network import @type on http(s) import #46936 (comment)

• import ConstJson from './config.json' as const; #32063

• Add support for URI style import #35749

• Remote declaration file #28985

• Maybe-countless mature features that ts dev don't have brandwidth to implement.

• Maybe-countless immature features that should better provide a simple way to let user implement.

💻 Use Cases

• script-able types for network import .ts

• script-able types for const/non-const json module

• script-able types for jsonschema

• script-able types for network import https://cdn

• script-able types for pnp-zip-like layer

• script-able types for database

• script-able types for webidl

• script-able types for future, for example, const/non-const yaml module

export default async function provider(
    importMetaUrl: ImportMeta["url"]
): Promise<null | dtsAST> {
    if (
        importMetaUrl === "http://git-server-with-correct-mime-type/example.ts"
    ) {
        const value = await read(importMetaUrl);
        return userUtils.ts2dts(value) as dtsAST;
    }

    if (jsonId.test(importMetaUrl)) {
        const { value, asConst } = await jsonId.parse(importMetaUrl);
        return userUtils.jsondts(value, { asConst }) as dtsAST;
    }

    if (jsonSchemaId.test(importMetaUrl)) {
        const value = await read(importMetaUrl);
        return userUtils.jsonSchema2dts(value) as dtsAST;
    }

    if (networkId.test(importMetaUrl)) {
        const { name, version, isSkypack, isEsmsh } =
            networkId.parse(importMetaUrl);
        return userUtils.npmdts({ name, version }) as dtsAST;
    }

    if (pnpzipId.test(importMetaUrl)) {
        const { name, version } = pnpzipId.parse(importMetaUrl);
        return userUtils.npmdts({ name, version }) as dtsAST;
    }

    if (importMetaUrl.endsWith("database-types")) {
        const dbconfigs: DBConfig[] = CONFIG.dbconfigs;
        return userUtils.dbdts(dbconfigs) as dtsAST;
    }

    if (webidlId.test(importMetaUrl)) {
        const value = await read(importMetaUrl);
        return userUtils.webidl2dts(value) as dtsAST;
    }

    // future-ish features, for example, yaml module
    if (yamlId.test(importMetaUrl)) {
        const { value, asConst } = await yamlId.parse(importMetaUrl);
        return userUtils.yamldts(value, { asConst }) as dtsAST;
    }

    return null;
}

Else

• Should provider be an async generator function, to inform typescript dts changes?

[MartinJohns]

Sounds like a duplicate of #41577 to me. Or #3136. Both found using your search terms.

[loynoir]

Sounds like a duplicate of #41577 to me. Or #3136. Both found using your search terms.

I consider two as subset of this feat.

[loynoir]

• import ConstJson from './config.json' as const; #32063 (comment)

• And consider network import CDN.

Thus, the solution should be implemented within user land, instead of within typescript.

[RyanCavanaugh]

We already have a disk-persisted format for types and consider this to be the preferred solution in every case listed here.

Throwing a Turing-complete compile-time type generator process into the mix is opening an infinite can of worms of complexity that we won't ever be able to close. Regenerating all of this stuff on every build is poison for performance, opens up a very significant new security boundary, makes it impossible for users to debug what's going on, creates problems in editor experiences (e.g. how do you "view" this source code?), and so on.