Skip to content
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

Migrate to TypeScript 2.1 #295

Closed
evmar opened this issue Dec 6, 2016 · 2 comments
Closed

Migrate to TypeScript 2.1 #295

evmar opened this issue Dec 6, 2016 · 2 comments

Comments

@evmar
Copy link
Contributor

evmar commented Dec 6, 2016

I started work on migrating to the TypeScript 2.1 API.

https://github.com/angular/tsickle/tree/ts2.1

@evmar
Copy link
Contributor Author

evmar commented Dec 22, 2016

I think we'll need to branch tsickle for this; we can't support TS<2.1 and TS2.1 simultaneously.

@fxck
Copy link

fxck commented Jan 3, 2017

any progress on this?

evmar added a commit that referenced this issue Jan 6, 2017
TypeScript 2.1 changed some APIs (which was easy enough to handle)
but it appears the representation of types is pretty different, so
I'm leaving that for a later change.

This change is enough to get tsickle to *compile* with TypeScript 2.1.
A bunch of type-related code is commented out (marked with "TODO(ts2.1)")
and many of the tests fail.

Initial work on #295.
evmar added a commit that referenced this issue Jan 7, 2017
TypeScript 2.1 changed some APIs (which was easy enough to handle)
but it appears the representation of types is pretty different, so
I'm leaving that for a later change.

This change is enough to get tsickle to *compile* with TypeScript 2.1.
A bunch of type-related code is commented out (marked with "TODO(ts2.1)")
and many of the tests fail.

Initial work on #295.
evmar added a commit that referenced this issue Jan 9, 2017
Make the main "translate" function match the enum in the
TypeScript API.  Split out the handling of more complex
Object types into a separate function, and adjust the code
there to use the new objectFlags field.

This actually makes most tests pass(!) but there are still
a few more to track down, and there are still a bunch of
TODOs.

More work on #295.
evmar added a commit that referenced this issue Jan 10, 2017
Make the main "translate" function match the enum in the
TypeScript API.  Split out the handling of more complex
Object types into a separate function, and adjust the code
there to use the new objectFlags field.

This actually makes most tests pass(!) but there are still
a few more to track down, and there are still a bunch of
TODOs.

More work on #295.
evmar added a commit that referenced this issue Jan 10, 2017
Make the main "translate" function match the enum in the
TypeScript API.  Split out the handling of more complex
Object types into a separate function, and adjust the code
there to use the new objectFlags field.

This actually makes most tests pass(!) but there are still
a few more to track down, and there are still a bunch of
TODOs.

More work on #295.
evmar added a commit that referenced this issue Jan 10, 2017
Booleans are represented as a union of true|false, but they
also have the boolean flag set so our existing code that handled
unions wasn't firing.

If we just treat them as unions, everything works, including more
complex cases (like boolean|number => true|false|number, without
the boolean flag set).

More work on #295.  With this change, the remaining failures in
tests are mostly whitespace.
evmar added a commit that referenced this issue Jan 10, 2017
Booleans are represented as a union of true|false, but they
also have the boolean flag set so our existing code that handled
unions wasn't firing.

If we just treat them as unions, everything works, including more
complex cases (like boolean|number => true|false|number, without
the boolean flag set).

More work on #295.  With this change, the remaining failures in
tests are mostly whitespace.
evmar added a commit that referenced this issue Jan 10, 2017
Booleans are represented as a union of true|false, but they
also have the boolean flag set so our existing code that handled
unions wasn't firing.

If we just treat them as unions, everything works, including more
complex cases (like boolean|number => true|false|number, without
the boolean flag set).

More work on #295.  With this change, the remaining failures in
tests are mostly whitespace.
evmar added a commit that referenced this issue Jan 10, 2017
NOTE: Some TypeFlags are marked "internal" in the API but still show
up in the value of type.flags.  Use a mask to limit the flag checks to
the ones in the public API.

More work on #295.  This fixes a crash in the "index_import" test.
evmar added a commit that referenced this issue Jan 10, 2017
NOTE: Some TypeFlags are marked "internal" in the API but still show
up in the value of type.flags.  Use a mask to limit the flag checks to
the ones in the public API.

More work on #295.  This fixes a crash in the "index_import" test.
evmar added a commit that referenced this issue Jan 10, 2017
NOTE: Some TypeFlags are marked "internal" in the API but still show
up in the value of type.flags.  Use a mask to limit the flag checks to
the ones in the public API.

More work on #295.  This fixes a crash in the "index_import" test.
evmar added a commit that referenced this issue Jan 10, 2017
Restore some code that special-cased tuple types.
Add some more test cases around tuples.

Rebaseline one test, because we added more test cases.
Note that this rebaseline also changes the type of {},
the empty object; I don't think it matters too much.

More work on #295. This fixes a crash in the "type" test.
evmar added a commit that referenced this issue Jan 10, 2017
Restore some code that special-cased tuple types.
Add some more test cases around tuples.

Rebaseline one test, because we added more test cases.
Note that this rebaseline also changes the type of {},
the empty object; I don't think it matters too much.

More work on #295. This fixes a crash in the "type" test.
evmar added a commit that referenced this issue Jan 10, 2017
Restore some code that special-cased tuple types.
Add some more test cases around tuples.

Rebaseline one test, because we added more test cases.
Note that this rebaseline also changes the type of {},
the empty object; I don't think it matters too much.

More work on #295. This fixes a crash in the "type" test.
evmar added a commit that referenced this issue Jan 10, 2017
Check in new goldens for the remaining tests, as the remaining
changes are expected.

Affected tests:
- enum: changed internal warning message
- fields: added a missing semicolon
- functions: tuple emit has changed slightly
- jsdoc, optional, super: empty function emit has changed slightly
- jsx: whitespace changes

Finishes work in #295 to prepare for TS2.1.
evmar added a commit that referenced this issue Jan 10, 2017
Check in new goldens for the remaining tests, as the remaining
changes are expected.

Affected tests:
- enum: changed internal warning message
- fields: added a missing semicolon
- functions: tuple emit has changed slightly
- jsdoc, optional, super: empty function emit has changed slightly
- jsx: whitespace changes

Finishes work in #295 to prepare for TS2.1.
evmar added a commit that referenced this issue Jan 11, 2017
Check in new goldens for the remaining tests, as the remaining
changes are expected.

Affected tests:
- enum: changed internal warning message
- fields: added a missing semicolon
- functions: tuple emit has changed slightly
- jsdoc, optional, super: empty function emit has changed slightly
- jsx: whitespace changes

Finishes work in #295 to prepare for TS2.1.
@evmar evmar closed this as completed in 349d0e5 Jan 11, 2017
rkirov pushed a commit that referenced this issue Jan 13, 2017
TypeScript 2.1 changed some APIs (which was easy enough to handle)
but it appears the representation of types is pretty different, so
I'm leaving that for a later change.

This change is enough to get tsickle to *compile* with TypeScript 2.1.
A bunch of type-related code is commented out (marked with "TODO(ts2.1)")
and many of the tests fail.

Initial work on #295.
rkirov pushed a commit that referenced this issue Jan 13, 2017
Make the main "translate" function match the enum in the
TypeScript API.  Split out the handling of more complex
Object types into a separate function, and adjust the code
there to use the new objectFlags field.

This actually makes most tests pass(!) but there are still
a few more to track down, and there are still a bunch of
TODOs.

More work on #295.
rkirov pushed a commit that referenced this issue Jan 13, 2017
Booleans are represented as a union of true|false, but they
also have the boolean flag set so our existing code that handled
unions wasn't firing.

If we just treat them as unions, everything works, including more
complex cases (like boolean|number => true|false|number, without
the boolean flag set).

More work on #295.  With this change, the remaining failures in
tests are mostly whitespace.
rkirov pushed a commit that referenced this issue Jan 13, 2017
NOTE: Some TypeFlags are marked "internal" in the API but still show
up in the value of type.flags.  Use a mask to limit the flag checks to
the ones in the public API.

More work on #295.  This fixes a crash in the "index_import" test.
rkirov pushed a commit that referenced this issue Jan 13, 2017
Restore some code that special-cased tuple types.
Add some more test cases around tuples.

Rebaseline one test, because we added more test cases.
Note that this rebaseline also changes the type of {},
the empty object; I don't think it matters too much.

More work on #295. This fixes a crash in the "type" test.
rkirov pushed a commit that referenced this issue Jan 13, 2017
Check in new goldens for the remaining tests, as the remaining
changes are expected.

Affected tests:
- enum: changed internal warning message
- fields: added a missing semicolon
- functions: tuple emit has changed slightly
- jsdoc, optional, super: empty function emit has changed slightly
- jsx: whitespace changes

Finishes work in #295 to prepare for TS2.1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants