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

feat(build): publish types as part of @ember/test-helpers #1196

Closed
wants to merge 15 commits into from

Conversation

buschtoens
Copy link
Contributor

@@ -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",
Copy link
Contributor Author

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.

Copy link
Contributor Author

@buschtoens buschtoens Aug 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chriskrycho

  • 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?

Copy link
Contributor

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!)

@chriskrycho
Copy link
Contributor

I just remembered this existed! 😓 @buschtoens if you can rebase and update, we'll get it published.

Copy link
Contributor

@chriskrycho chriskrycho left a 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
Copy link
Contributor

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.

Comment on lines +6 to +10
/**
* @internal
* @see {@link https://github.com/glimmerjs/glimmer-vm/blob/v0.84.0/packages/@glimmer/interfaces/lib/template.d.ts#L29-L55}
*/
type Template = {};
Copy link
Contributor

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.

Suggested change
/**
* @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'>;

@buschtoens
Copy link
Contributor Author

@chriskrycho Sure! I'll try to get to it in the next hours. Thanks for picking this up again. 🥳

@chriskrycho
Copy link
Contributor

So sorry I let it sit for so long! Just fell off my radar, as these things do!

@chriskrycho
Copy link
Contributor

@buschtoens also relevant: #1234, which… may… supersede this? (I had obviously really forgotten about this PR. 😢)

@chriskrycho
Copy link
Contributor

Going to go ahead and close this as superseded by a number of other commits; thanks again for getting it started @buschtoens!

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

Successfully merging this pull request may close these issues.

2 participants