-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
feat(build): publish types as part of @ember/test-helpers
#1196
Conversation
Fixes emberjs#596. Includes a fix for building from `.ts` source files. documentationjs/documentation#1484
@@ -61,7 +61,7 @@ | |||
"@typescript-eslint/parser": "^4.29.0", | |||
"broccoli-babel-preset-typescript": "^1.0.1", | |||
"broccoli-merge-trees": "^4.2.0", | |||
"documentation": "^13.2.5", | |||
"documentation": "npm:@buschtoens/documentation@13.2.6", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to consider taking this opportunity to switch to a more well-maintained tool, like API Extractor. That would also improve the .d.ts
build process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should I keep pointing at my fork here?
- Or should we switch to a different tool like API Extractor first? If so, ...
- Which tool would you prefer?
- Should this be split out into an extra PR that is merged before this one?
- Or do you have a completely different solution to this in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're exactly right directionally! Let's see if we can get TypeDoc wired up to do what we want. TypeDoc is almost certainly what we're going to end up using for Ember itself; it is how we are doing all of our TS-powered docs-generation at LinkedIn; and it is what I've used most successfully on other TS projects.
(API Extractor is (a) barely maintained at this point and (b) uninterested in supporting anything other than single-entry-point Node-style packages. TypeDoc is well-maintained, open to contributions, and actively working on supporting things like package exports
maps. If we find gaps, let's help fix them there!)
I just remembered this existed! 😓 @buschtoens if you can rebase and update, we'll get it published. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a couple comments in flight. I'm sure there will be more.
@@ -93,6 +93,7 @@ if (typeof URLSearchParams !== 'undefined') { | |||
if (disabledDeprecations) { | |||
registerDeprecationHandler((message, options, next) => { | |||
if (!disabledDeprecations.includes(options.id)) { | |||
// @ts-expect-error https://github.com/DefinitelyTyped/DefinitelyTyped/pull/59014 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's avoid referring to DT-specific issues if possible, because these comments will get stale very quickly as a result. Documenting why they don't work and linking to an issue which tracks it seems fine.
/** | ||
* @internal | ||
* @see {@link https://github.com/glimmerjs/glimmer-vm/blob/v0.84.0/packages/@glimmer/interfaces/lib/template.d.ts#L29-L55} | ||
*/ | ||
type Template = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least for this one, we probably want to use the same "opaque type" trick we are using for similar interfaces across the ecosystem (with an eye to unifying all of them as we go forward). Otherwise, as a return type, it's usable as "any old object" and people can "construct" it themselves.
/** | |
* @internal | |
* @see {@link https://github.com/glimmerjs/glimmer-vm/blob/v0.84.0/packages/@glimmer/interfaces/lib/template.d.ts#L29-L55} | |
*/ | |
type Template = {}; | |
declare const Brand: unique symbol; | |
declare class Opaque<T> { | |
private [Brand]: T; | |
} | |
/** | |
* @internal | |
* @see {@link https://github.com/glimmerjs/glimmer-vm/blob/v0.84.0/packages/@glimmer/interfaces/lib/template.d.ts#L29-L55} | |
*/ | |
interface Template extends Opaque<'Template'> {} |
This provides a value that is only constructible internally (and via methods we provide) rather than something which folks can just pass an object as (and have it potentially go 💥).
Note that it's fine to do type Template = ...
as long as you don't care about it being interface-mergable later, and in fact that's a useful tool for exactly that scenario (where you want to make the type "closed" rather than "open"):
type Template = Opaque<'Template'>;
@chriskrycho Sure! I'll try to get to it in the next hours. Thanks for picking this up again. 🥳 |
So sorry I let it sit for so long! Just fell off my radar, as these things do! |
@buschtoens also relevant: #1234, which… may… supersede this? (I had obviously really forgotten about this PR. 😢) |
Going to go ahead and close this as superseded by a number of other commits; thanks again for getting it started @buschtoens! |
Build and publish the TypeScript
.d.ts
files as part of@ember/test-helpers
to obsolete@types/ember__test-helpers
.registerWarnHandler
®isterDeprecationHandler
DefinitelyTyped/DefinitelyTyped#59014fix(exported): respect
parse-extension
&require-extension
documentationjs/documentation#1484