microsoft / microsoft/TypeScript

[Feature Request] A way to specify preference to emit `typeof` a variable instead

Abierto
#32,977 0 comentarios 0 reacciones 1 asignado Ver en GitHub

@weswigham ya está trabajando en esto.

Desde el 21/8/2019.

Needs Investigation
Lenguaje dominante
Go
Estrellas
111k
Forks
14.4k
Merge medio
1 d 19 h
PR fusionados (30 d)
117

Descripción

Search Terms

emit, typeof, variable

Suggestion

I'm just opening this issue so I have somewhere to refer to.
I don't necessarily think this is a good idea.
I'm just thinking about a problem I have aloud.

It would be nice if I had a way to annotate when I would prefer emit to use typeof variable instead of emitting the variable's type.

type SomeType<T> = { x : T };
//Unsure of what syntax to use
type SomeType2<typeof T> = { x : T };

const variable = { prop : "value" };

/*
Expected:
type Foo = {
    x: {
        prop: string;
    };
}
*/
type Foo = SomeType<typeof variable>;

/*
Expected:
type Foo2 = {
    x: typeof variable;
}
*/
type Foo2 = SomeType2<typeof variable>;

/*
Expected:
type Bar = {
    x: { prop : "value" };
}
*/
type Bar = SomeType<{ prop : "value" }>;

/*
Expected:
type Bar2 = {
    x: { prop : "value" };
}
*/
type Bar2 = SomeType2<{ prop : "value" }>;

declare function f_1_1<T> (t : T) : SomeType<T>;
declare function f_1_2<T> (t : T) : SomeType2<T>;
declare function f_2_1<typeof T> (t : T) : SomeType<T>;
declare function f_2_2<typeof T> (t : T) : SomeType2<T>;

//Expected: { x: { prop: string } }
export const r_1_1 = f_1_1(variable);
//Call-site does not have preference for `typeof` emit
//Expected: { x: { prop: string } }
export const r_1_2 = f_1_2(variable);

//Expect to propagate preference to emit `typeof`
//Expected: { x: typeof variable }
export const r_2_1 = f_2_1(variable);
//Expected: { x: typeof variable }
export const r_2_2 = f_2_2(variable);

/*
Variable with nested properties
*/
const baz = { a : { b : { c : "hi" } } };
//Expect to propagate preference to emit `typeof`
//Expected: { x: typeof baz.a }
export const r_2_1 = f_2_1(baz.a);
//Expected: { x: typeof baz.a }
export const r_2_2 = f_2_2(baz.a);

It's just a preference. If such an emit can't be done, then it falls back to the default emit behaviour.

Use Cases

My use case is that one of my subprojects initially spent 15s on check but 45s on emit.
A lot of it is because it's expanding the type of some variables (110+ lines) when it can just use typeof variable (1 line)

Right now, it's at 18s to check, 47s to emit.

If I can make it emit typeof variable for the parts where it is possible,
I can probably reduce my emit size and time by a lot.


A SQL table has a bunch of columns, primary keys, candidate keys, etc.

For type-safe JOIN clauses and expressions in a query builder, these expressions, clauses, queries, etc. need to have information about the table(s) being used be part of their generic type param.

However, because TS always expands the type as much as possible, I end up with 110+ lines when a simple typeof myTable or typeof myTable.columns or typeof import("../table").myTable or typeof import("../table").myTable.columns would do in most cases.

I'm still trying to trim the amount of information each type needs about a table but there's just no escaping that a lot of information is still needed for SQL queries to be checked properly during compile-time.


Examples

See above suggestion.

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, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.