* Numeric literal assignable to enum literal only when values match
* Accept new baselines
* Update compiler sources
* Accept new baselines
* Fix test runner
* Any numeric literal type is assignable to a computed numeric enum type
* Refactor `Extensions`, fix lookup priorities
* Update baselines
* Clean up
* Temporarily apply same fix to `node` for testing
* Revert ancestor node_modules lookups back to two passes
* Revert "Temporarily apply same fix to `node` for testing"
This reverts commit 4014f3005a2a01a5c71a88e6418cc635498a83bc.
* Update baselines
* Add new test for node_modules searching behavior
* Update new baseline
* Add tests where typeRef resolution is not in the cache
* Ensure that type ref reuse is actually handled since type ref resolution only sends containingSourceFileMode and not containingSourceFile
* Remove unnecessary redirection now that we are not in namespaces
* Move the tsc helpers in one place
* Move virtual file system with watch in unittests folder instead of harness since harness doesnt use it anyways
* Replace protocol and commandNames
* Revert incorrect pick
* Add known keys of the mapped type constraint to its members
* Avoid second pass of adding known members by instead passing `noReductions` to `mapType`
It turns out that the import expression won't actally be rewritten by
esbuild, so we can just write it directly.
While this won't help CJS emit, that already didn't work anyway, and
it's likely that this code is going to be moved outside of the codebase
into VS Code or a shared package elsewhere anyway.
The troubleshooting wizard for the debugger actually says that this
option is no longer recommended; removing it enables us to use source
maps if we happen to be debugging while in --bundle=false mode.
Looking at github, sourcegraph, and internally, nobody appears to use
this factory at all.
It's still used within our testing framework, so I won't remove it, but
we shouldn't be polyfilling globalThis and sticking things onto it these
days.
This debug code was added quite a while ago, constructed such that we
wouldn't have to ship this code to our users.
However, this is the sole place in the compiler project where the ts
namespace "escapes" the bundle. By moving this debug code into the
compiler itself, we no longer have any references to the ts namespace
itself for our bundles that don't export anything (tsc,
typingsInstaller). This lets bundlers tree shake the compiler, reducing
the size of our output by _5.7 MB_ (a ridiculous improvement for
_adding_ code).
We pass the entire "ts" object into plugins. However, we need to make
sure that that object contains the debug compat helpers.
In the old codebase, the deprecated compat code would tack things onto
the actual ts object, after the server code was executed, and later that
same object would be given to plugins.
But in modules, each TS project only sees the view of the "ts" namespace
that their references implied, not the ts object as some sort of
singleton. To ensure that plugins get the debug compat code, we have to
bring that into each project's view of the ts namespace, and not add it
on later in the executable projects.
Unlike our other exectuables, tsserver is used in web, which means that
there actually would have been a "ts" variable declared for those users
(e.g. in a web worker). It looks like VS Code needs this variable to be
declared, so change this bundle to look the same as other libraries.
Note that in Node, the IIFE will never actually return, so this can have
no effect. On web, it will return in order to yield control back to the
event loop (as on web, postMessage is used to communicate).
