embroider-build
Add type-tests
Resolves https://github.com/embroider-build/addon-blueprint/issues/142 (<- also context)
Requires: https://github.com/embroider-build/addon-blueprint/pull/158
type-tests have become a pattern in TS-using v1 and v2 addons to help ensure that APIs maintain consistent and expected typings across TS upgrades.
the typed-ember team has recommended this approach on other v2 addons, and it is in used in ember-source.
If active members of the TS team have other opinions I'll happily defer to them, but my general take is that a typical TS addon shouldn't need type tests. In my experience, dedicated type tests are useful in two scenarios:
- your addon and its tests are written in JS, and you want to verify that your hand-authored declarations work as expected
- you're doing a significant amount of programming in the type system itself and want to "unit test" pieces of that logic at a very fine-grained level
For an addon authored in TypeScript, neither of these situations will usually apply, and I think it's generally going to be more productive to treat your actual runtime tests as effectively being end-to-end tests of your types.
Having good examples to point to for cases where authors do need type tests is great! But I don't think those cases are likely common enough that we should bake support into the default blueprint.
type-tests have become a pattern in TS-using v1 and v2 addons to help ensure that APIs maintain consistent and expected typings across TS upgrades.
the typed-ember team has recommended this approach on other v2 addons, and it is in used in ember-source.
I am curious, seems this is contrary to what Dan said above. Do you have examples for these type-tests in real addons? And do they qualify as needed tests, in regard to the two scenarios Dan mentioned above?
Do you have examples for these type-tests in real addons?
ember-resources, ember-modifier, @ember/test-helpers, ember-async-data, ember-qunit, and ember-source (off the top of my head)
And do they qualify as needed tests, in regard to the two scenarios Dan mentioned above?
I think so, they each do goofy types-related things for various reasons.
- types not the same as implementation
- types jumping through hoops for Glint support
I am curious, seems this is contrary to what Dan said above.
Well, recommend for all and recommend for those that need them is probably the difference here. For example, i wasn't using expect-type when i started type testing, and typed ember team was like, 'this tool is really good, you should use it'