Convert the addon to TypeScript #23
Conversation
|
As a follow-on for this (early next week) I will add support for testing against a range of TypeScript versions, including I propose the following guidance around supported TypeScript versions:
|
|
In general, that policy seems good to me overall though I don't know that the 4th point will work in practice (if users can't make a modifier using ember-cli-typescript and we can fix it, we probably should do the major bump release regardless of Ember's LTS cycle). |
|
@rwjblue that's fair for sure; that was definitely the most conservative aspect of this. (To be clear the only thing being blocked would be upgrading to a new TS version, rather than continuing to use e-c-ts as normal, but even so!) On reflection, though, maybe we aim to be that conservative only around dropping supported versions? It's not so big a deal to cut a breaking change that has a minor change; I take it to be a slightly (?) bigger deal to remove a supported version from the matrix. |
|
To be clear, I think we should work on landing this without the refactors that I mention in my comments (though we should still make a todo issue and link to it in the code), but there are some more fundamental things that I do think we should fixup before landing (allowJs and ember-cli-babel version) |
Ya, this makes the most sense to me. Revving majors is "fine" (for the most part), but we do have to be somewhat careful about the poor merging behavior that ember-cli gives us by default (though that is an issue for a different repo 😝). |
chriskrycho
force-pushed
the
typescript
branch
2 times, most recently
from
5e5bca5
to
903a36d
Compare
- Add `ember-cli-typescript` to build TS assets, and `expect-type` to
verify the types exported publicly.
- Convert implementation and tests to TypeScript. Add type tests to
constrain the public API.
- Add docstrings to the publicly exported items for better editor
feedback.
- Update the README:
- Elaborate the TS docs, including full TS examples, explanations, and
important caveats.
- Add a table of contents.
- Fix some grammatical issues.
- Move the explanation of what the addon *is* above its note on the
original contributors.
There was a problem hiding this comment.
The changes here look good to me, thanks for working through all of my annoying quibbles @chriskrycho!
I am curious what the path forward is for the versioning issue. How do we properly test on supported TypeScript versions? Should we consider landing this with an intentionally invalid types entry in package.json so that we can land the refactor while we work through the actual policy issues?
| @@ -0,0 +1 @@ | |||
|
|
|||
There was a problem hiding this comment.
Do we need this empty file? What does it do for us?
There was a problem hiding this comment.
We don't! I'll remove it!
|
@rwjblue my thought on landing this was that we would do basically this sequence:
That said, I'm perfectly fine with switching the order and doing (5) before (3), and accordingly not publishing types. |
|
I don’t have a strong preference other than that we have to deal with the SemVer / TS issue before publishing types officially. I believe that we are on the same page here though, so I’m perfectly happy to go in whatever order you prefer. |
|
100% agreed that we have to nail that down before publishing! See #30 – I'll publish a draft there of the revised proposal I came up with after conversation here and talking with other Typed Ember folks. |
Add
ember-cli-typescriptto build TS assets, andexpect-typeto verify the types exported publicly.Convert implementation and tests to TypeScript. Add type tests to constrain the public API.
Add docstrings to the publicly exported items for better editor feedback.
Update the README:
Supersedes and therefore resolves #9, and thereby also resolves #8.