-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
export TypingsInstaller from tsserverlibrary #53394
export TypingsInstaller from tsserverlibrary #53394
Conversation
07ed201
to
ad45060
Compare
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
1 similar comment
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
@@ -5846,6 +5846,14 @@ declare namespace ts { | |||
emit(writeFile?: WriteFileCallback, customTransformers?: CustomTransformers): EmitResult | BuildInvalidedProject<T> | undefined; | |||
} | |||
type InvalidatedProject<T extends BuilderProgram> = UpdateOutputFileStampsProject | BuildInvalidedProject<T> | UpdateBundleProject<T>; | |||
namespace JsTyping { |
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.
Somewhat unfortunate that this is making it out into the non-server API given there's no actual use for it...
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.
What do you mean? The TypingResolutionHost is something I really would have to implement, iiuc
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.
Sure, but this is typescript.d.ts, not tsserverlibrary.d.ts, and it's not going to contain the ATA stuff as far as I'm aware (note that the change to this file is type-only).
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 am pretty sure this is unnecessary if we just switch these to direct import instead of leveraging the following re-export from within src/services/_namespaces/ts.ts
:
export * from "../../jsTyping/_namespaces/ts";
@zkat I think that's a reasonable change to make within this PR.
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.
@DanielRosenwasser You mean doing import { TypingResolutionHost } from "./jsTyping;"
? 'cause that broke the tests because it can't find it?? (sorry, I'm not entirely understanding how the namespace mapping thing works right now)
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.
Yeah, our bundling is unfortunately far too restrictive to allow this sort of thing right now. I think it's just going to have to be gross.
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.
Hold up, why can't the tests just do a direct import as well?
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.
Bump
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.
@zkat if you change existing instances of TypingResolutionHost
to direct imports in the test suite, does the bundler still "break"?
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.
Okay, I just realized that we (just below here) already have ts.server
declared in typescript.d.ts
. This isn't a regression; you can see the same thing in TS 4.9.5 too.
So, I think I'm okay with this PR as-is. It's no worse than our current API in terms of over-declaring a public API. ATA already leaks into typescript.d.ts
as it is so I don't think there's really much to do here.
ad45060
to
c998d7a
Compare
@@ -31,7 +31,6 @@ import { | |||
versionMajorMinor, | |||
} from "./_namespaces/ts"; | |||
|
|||
/** @internal */ |
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.
Instead of removing internal can we re-export it in server as some other name so that typescript.d.ts doesnt change.
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.
This may not actually work under the naive dts bundler, actually, but we'd have to try.
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.
Per my last comment, I think that this is fine, even though it over-declares stuff into the non-server API file.
It turns out that we already over-declare in typescript.d.ts and had been doing that from the start, all thanks to jsTyping
. If we had been using regular imports rather than namespace merging, we would have split this code apart a lot differently than what it has ended up as now.
I think that fixing that needs to be a separate API change not in this PR.
@sheetalkamat @DanielRosenwasser Are you alright with this PR as-is, given the above? |
Fixes #53414
This exports interfaces necessary for external implementers of ITypingsInstaller and extenders of TypingsInstaller.