10

I am trying to create more simplified output in the *.d.ts typescript files which are included with the bundled version of my modules code. These files are generated through a chain involving the typescript compiler, babel, and rollup. I am also using relay and graphql, but I don't think that will impact the question much.

As an example, in the .tsx source code, I have something like this:

import { graphql } from 'babel-plugin-relay/macro'

// produces some generated code 
graphql`fragment task_model on Task { id message createdAt deadline modifiers { hard medium easy } }`

// There is a generated type for this fragment, but it is a little ugly
import { task_model } from './__generated__/task.graphql'

// We can "correct" the type information and export it with a nicer name
export type Task = Readonly<Omit<task_model & { deadline: string, createdAt: string }, ' $refType'>>

In the .d.ts output, the file says:

export declare type Task = Readonly<Omit<task_model & {
    deadline: string;
    createdAt: string;
}, ' $refType'>>;

But, within a capable IDE, I can see that type resolves to a more sensible

type Task = {
    readonly id: string;
    readonly message: string;
    readonly createdAt: string;
    readonly deadline: string;
    readonly modifiers: {
        readonly hard: number;
        readonly medium: number;
        readonly easy: number;
    };
}

Is if there is some option or some way to output the cleaner human readable type resolution, instead of the version which describes the corrections? I think it would be nice to be able to understand the type information even if the project using the module is not properly configured to use it.

jswidler
  • 355
  • 1
  • 10
  • 1
    I think there is a maintenance reason behind this: if the `task_model` type changes for some reason in the original library, also your `Task` type would change if you describe it as `Readonly>`. On the opposite if you want `Task` to be the way your IDE resolves, you should describe it as that. (with this I mean that I dubt there will be an official way for TS to support an operation similar to your intents) – DDomen Oct 19 '21 at 22:11
  • @DDomen, that’s a good reason not to do it for all types. But for generated types it could be a nice cleanup with readability and perhaps performance improvements. So I’m still interested for that specific use case. – Michiel Oct 20 '21 at 08:31
  • 1
    As far as I know, IDE's do this using the map file. Basically that maps your compiled distribution file to your source code. There is no straight forward way to do it, but you could be able to script it. You would have to look at the map file, go to the source file, check the imports and then search for their compiled files. I could prototype something like this if you thing it would help – Bogdan Condurache Oct 26 '21 at 11:56

0 Answers0