-
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
Watch improvements in tsserver #17269
Conversation
…d to update the project by re-reading the config file This will improve the opening file perf for file opens from same config project
…ect update Also reload the projects when extra extension in the host change
…t on the disk This helps in reporting errors as well as syncing of the configured/external project when the files are created
…update and delete This will ensure that the calling of watches doesnt rely on writing test correctly
…e files open from that project
… the configured projects for open files from that project to ensure to pick them by another config file that can be present in parent directory
…ve missing file watching as well We dont need to explicitly watch config file directory as it will be watched: - if there was no files specified, in wild card directories - if there were files specified as missing file (if the file wasnt present)
…e it is possible to schedule the update graph of project
…nce we watch the needed files
…t read directory or getDirectories
…batching the updates when there are multiple files added/removed/changed
This should speed up the file open scenarios where the file belongs to same configured project as we would use cache to answer those fileExists answers
…in case of inferred root
src/compiler/builder.ts
Outdated
} | ||
|
||
// Return array of values that needs emit | ||
return arrayFrom(seenFileNamesMap.values()); |
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 this filter out just the non-undefined
values? seenFileNamesMap
will have an undefined
entry for anything that shouldn't be emitted.
signature: string; | ||
} | ||
|
||
export function createBuilder( |
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.
Do we want this to be a new public API?
(If so it would be a good idea to take an options object instead of taking many positional arguments.)
getFilesAffectedByUpdatedShape | ||
}; | ||
|
||
function getFilesAffectedByUpdatedShape(program: Program, _sourceFile: SourceFile, singleFileResult: string[]): string[] { |
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.
It looks like this would be simpler if it took and returned SourceFile[]
instead of string[]
.
Then you can call onAffectedFile(file.fileName, file);
instead of onAffectedFile(file, program.getSourceFile(file));
(Also, since file.fileName
can trivially be derived from file
, you could skip passing that into the callback too.)
You might similarly change the return type of getFilesAffectedBy
. to SourceFile[]
.
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.
getFilesAffectedByUpdatedShape is used by project to get affected file names, so this works out better than sending source files so that project doesnt need to iterate on the list to convert that to file names.. In rest of the cases, you can always get the source file from file name
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.
But, it's simpler to get the filename from a source file (sf.fileName
) than it is to get the source file from a file name (requires a lookup table).
e38a707
to
898559b
Compare
@andy-ms and @mhegazy Please let me know if there is any other feedback |
src/compiler/builder.ts
Outdated
text: string; | ||
} | ||
|
||
export interface ChangedProgramFiles { |
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.
do you still need this?
src/compiler/builder.ts
Outdated
/** | ||
* This is the callback when file infos in the builder are updated | ||
*/ | ||
onProgramUpdateGraph(program: Program, hasInvalidatedResolution: HasInvalidatedResolution): void; |
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 do not think we need graph
in the name of this function, users do not need to know how we represnet the files.
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.
Nit, i would call program
as newProgram
.
…red out final details
6f35ad4
to
7f969e8
Compare
clear(): void; | ||
} | ||
|
||
interface EmitHandler { |
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 should be intrnal too
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.
consider spiting this into two namespace ts {
declarations
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 isnt public interface anyways ?
let's get the functional changes in, i would like to make some changes to the API, but we can make these in a separate PR. |
…terfaces and functions
* Tests whether a value is string | ||
*/ | ||
export function isString(text: any): text is string { | ||
return typeof text === "string"; |
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 is likely a minor slow-down, for no benefit to readability.
Functions that are called with polymorphic arguments are quickly de-optimised. This one is specifically intended to be called with polymorphic arguments, so it's very likely to be de-optimised and become slower than conventional idiomatic typeof === 'string'
.
Worth checking with a timed run.
This is the first stage of pulling out builder api. It factors out a lot of things that project did, when it was reloaded, when/how we lookup for the tsconfig files, and what we cache.
It will fix many bugs and I will include that list as I add the test scenarios for them.
refreshInferredProjects
was called #17178, TSServer Reference requests taking a long time #17385, TypeScript watcher consumes large amount of CPU when idle. #17506, Probably FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory #18411 since it talks about leak with tsc --watchtsc --w
using the CoS builder #10879Here is detailed list of changes done as part of this PR: