Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
5 tasks done
AnyhowStep opened this issue Aug 19, 2019 · 0 comments
Open
5 tasks done
Assignees
Labels
Needs Investigation This issue needs a team member to investigate its status.

Comments

@AnyhowStep
Copy link
Contributor

AnyhowStep commented Aug 19, 2019

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

3 participants