Keep the DocumentRegistry b/t watch cycles instead of resetting it
Follow-up to my findings in #386, 3. specifically
Potential fix for the OOM in #177, but difficult to tell since there's no repro and it's coming from TS itself
Details
we can re-use the same one during watch instead of resetting it in the options hook
should make the LS a bit faster / more efficient in watch mode as most source files are shared between watch cycles
Potential Further Optimizations
DocumentRegistry can actually be shared between multiple LSes for #177. Per the TS LS Wiki, sharing DocumentRegistry is actually recommended, as, minimally, lib.d.ts could be shared between projects.
But to do that we'd probably have to expose an option for it and users would have to opt-in. On second thought, this might not even be useful for #177 since those are separate processes that don't share variables 😕
Thinking about it one step further... we could actually create the DocumentRegistry as a top-level var, before the plugin is instantiated... that would make DocumentRegistry shared between all imports of rpt2... but it would still be limited to only the same Node process... so guess that's probably not useful either in this case 😕
And the top-level instantiation could be a bit hacky since tsModule isn't set till plugin instantiation (as visible in this PR, where the DocumentRegistry is only instantiated after tsModule is set)...
Leaving it as is here, as a result then
It's possible we can avoid recreating the LS itself between watch cycles. That would be optimal. I believe we'd be able to do that if the parsedConfig hasn't changed between watch cycles, which is probably the most common usage of watch anyway, i.e. changing source files and not config
Summary
Keep the
DocumentRegistry
b/t watch cycles instead of resetting it3.
specificallyDetails
options
hookPotential Further Optimizations
DocumentRegistry
can actually be shared between multiple LSes for #177. Per the TS LS Wiki, sharingDocumentRegistry
is actually recommended, as, minimally,lib.d.ts
could be shared between projects.DocumentRegistry
as a top-level var, before the plugin is instantiated... that would makeDocumentRegistry
shared between all imports of rpt2... but it would still be limited to only the same Node process... so guess that's probably not useful either in this case 😕tsModule
isn't set till plugin instantiation (as visible in this PR, where theDocumentRegistry
is only instantiated aftertsModule
is set)...parsedConfig
hasn't changed between watch cycles, which is probably the most common usage of watch anyway, i.e. changing source files and not config