Generates corresponding .d.ts file

[cschroeter]

It would be great if we could specify (like source maps) an option to also generate declaration files.

[kdy1]

I've been agonized if it is possible without fully blown typescript parser. I thinks it's not possible yet.

(I'm working on a fully-blown typescript compiler, but It would take some time.)

[cschroeter]

Okay, I get it. Unfortunately the advantage of swc is kind of lost when you need the declaration files, since you have to run tsc --emitOnlyDeclaration anyway

[kdy1]

Reopening as I checked an output from tsc and I noticed that it's possible without a full type checker.
My ts checker branch (already) contains enough code to emit types of correct typescript files.

Currentlly it cannot infer the type of parameter, but it's okay as d.ts contains it as-is

[cschroeter]

If this were to work, that would be wonderful

[behnammodi]

Hi there, has any progress?

[eric-burel]

Hi, I've commented on Esbuild a similar issue, but same question for SWC: could you at least point users to a possible pattern/documentation/resource to generate the .d.ts files?

I don't think .d.ts should be regenerated all the time, it's often ok to generate them only when publishing the app for instance. So we could keep using tsc or whatever for this step. However I completely fail to find some decent documentation about how to just generate those files after the build, with either tsc or ts-loader.

[kdy1]

@behnammodi #571 is used instead of this issue, as generating .d.ts files requires full typescript type checker.

@eric-burel TypeSciprt is a huge beast and porting it is not easy. It's simply not support neither by esbuild nor swc at the moment.

[eric-burel]

Yeah I get that the port is hard, no problem with that, but is there a palliative that could use swc + any other solution that could focus on just the .d.ts? While waiting for a full port?

It seems to me that if I use swc-loader (in replacement to babel-loader) coupled ts-loader in my webpack config, there are redundant build operations so the gain is limited.

For instance, I'd like ts-loader to just focus on creating the .d.ts, which might be faster than actually building/type checking, but I am not sure if that make sense and I haven't found any thread about that. Again maybe what I am asking doesn't make sense from a technical standpoint, I don't really know.

[kdy1]

is there a palliative that could use swc + any other solution that could focus on just the .d.ts? While waiting for a full port?

No. It's simply impossible. You need full type system to generate .d.ts files.

[bfaulk96]

@kdy1 Man, I wish Microsoft would realize how valuable this is and just hire you to replace their current TS type system with the Rust-based one you're working on 😅

[ghost]

You need full type system to generate .d.ts files.

Why? You'd of course need a full type system to validate types, but to generate the .d.ts files can't you just pass the types through from src->.d.ts without checking anything?

[edit] Assuming all types are explicit. I feel like generating .d.ts files with any/unknown for types that aren't explicitly defined would be a great step

[kdy1]

Bexause you can't know type

[ghost]

You need to be able to parse types, but you don't need to understand them (e.g. need a full type system):

import { whatever, somethingElse } from 'file';
export function foo(x: whatever): somethingElse {
  // implementation
}

can be used to create a .d.ts of:

import { whatever, somethingElse } from 'file';
export declare function foo(x: whatever): somethingElse;

[kdy1]

No you can't know the type id it's not specified.

(All validations are not required for generating .d.ts, but I don't think you meant this)

[ghost]

What am I missing, lol? I don't see why you need type ids to generate a .d.ts.

Let's say you matched somethingElse in my example above. You don't care if that's literally somethingeElse, string, or Promise<[Array<Err | null> | null, UnpackAllOrNull<T>]>. If you copy it 1:1 into a .d.ts file, that's valid, no?

[kdy1]

No.

function foo<T>(arr: T[]) {
    for (const a of arr) {
        if (typeof a === 'string') return a
    }
} 

Do you think you can generate the .d.ts without full type system?

[ghost]

Assuming all types are explicit.

😁

All of ours are anyway, because we've enabled typescript-eslint/explicit-module-boundary-types. I realize this is a pretty large limitation, but it's not necessarily a bad one. You don't want exported types randomly changing, so explicitness is good here anyway.

[kdy1]

I don't think the user of a feature like that is many enough to justify the effort required for this.

[casamia918]

I really need this feature. My project is monorepo. So, I want to transpile shared package by using swc.
But as the d.ts file is not generated, I should still use tsc instead.

[XiNiHa]

I really need this feature. My project is monorepo. So, I want to transpile shared package by using swc. But as the d.ts file is not generated, I should still use tsc instead.

When referencing other packages' types that are in the same workspace, you don't have to build .d.ts files since they're just TypeScript source files.

[onichandame]

I really need this feature. My project is monorepo. So, I want to transpile shared package by using swc. But as the d.ts file is not generated, I should still use tsc instead.

When referencing other packages' types that are in the same workspace, you don't have to build .d.ts files since they're just TypeScript source files.

In the context of monorepo I believen packages live in different workspaces. After all yarn v2 uses the word workspace as a synonym to package.

[XiNiHa]

In the context of monorepo I believen packages live in different workspaces. After all yarn v2 uses the word workspace as a synonym to package.

@onichandame According to the documentation, a workspace itself is a package. However, it also hosts several sub-projects which are also packages. Therefore a single workspace package hosts many sub-packages, and the sub-packages can cross-reference each other.

[fguitton]

How exciting, Vercel would be supporting the effort ! https://kdy1.dev/posts/2022/1/tsc-go 🥳

[ShivamJoker]

Any updates on this? If we want to publish our packages on npm this wont be ideal solution

[eric-burel]

@ShivamJoker check the linked article https://kdy1.dev/posts/2022/1/tsc-go
At the moment you need tsc to generate .d.ts and .d.ts.map

And example tsconfig could be:

{
  "extends": "./tsconfig.json",
  "include": [
    "./shared/index.ts",
    "./client/index.ts",
    "./server/index.ts"
  ],
  "compilerOptions": {
    "emitDeclarationOnly": true,
    "isolatedModules": false,
    "declaration": true,
    // helps local development, could be dropped out of the NPM package though
    "declarationMap": true
  },
}

[ShivamJoker]

okay so there is gonna be a new lib which will have all these features?

[kdy1]

It will be added to swc

[mechadragon01]

Is there a timeline for this?

[alexn-s]

are there any news for this feature?

[sayjeyhi]

@kdy1 any progress on this?

[kdy1]

Update: See https://github.com/dudykr/stc