needsUpdate may be wrong when the branch changes; these ones are now so
fast thanks to being pure JS that we can just always run their contents
and be sure that the outputs are right.
This file is pretty much the same as it was when it was committed in
2017; these days, we can write clearer code with async/await and new FS
APIs.
Additionally, we can improve the performance of this script by using a
newer/faster/maintained XML library. This will enable us to run the
script unconditionally in a later commit.
Profiling the build roughly half of the time spent loading the
build is spent importing typescript.js, for this one function.
Since this stack is already adding required devDependencies, switch
readJson to use jsonc-parser (published by the VS Code team), rather
than importing the entire LKG typescript.js library.
This eliminates a significant number of dependencies, eliminating all
npm audit issues, speeding up `npm ci` by 20%, and overall making the
build faster (faster startup, direct code is faster than streams, etc)
and clearer to understand.
I'm finding it much easier to make build changes for the module
transform with this; I can more clearly indicate task dependencies and
prevent running tasks that don't need to be run.
Given we're changing our build process entirely (new deps, new steps),
it seems like this is a good time to change things up.
This adds a "small" d.ts bundler script. This script is very basic,
using Node printing to produce its output. Generally speaking, this is
inadvisable as it completely disregards name shadowing, globals, etc.
However, in our case, we don't care about the globals, and we can opt to
restructure our codebase in order to avoid conflict, which we largely
had to do anyway when we were namespaces and everything was in scope.
This configures the existing build tasks to use esbuild by default. If
using the plain files is desired, passing `--bundle=false` will build
using plain files and still produce a runnable system.
This is only a basic build; a more efficient build is provided later
when gulp is replaced by hereby.
If these are regular comments, then they won't appear in our d.ts files.
But, now we are relying on an external d.ts bundler to produce our final
merged, so they need to be present in the "input" d.ts files, meaning
they have to be JSDoc comments.
These comments only work today because all of our builds load their TS
files from scratch, so they see the actual source files and their
non-JSDoc comments.
The comments also need to be attached to a declaration, not floating,
otherwise they won't be used by api-extractor, so move them if needed.
Now that we are modules, there's no reason to ban multiple namespaces
per file; each file is its own scope and declaring a namespace won't
merge it into any other files.
* Prototype TS plugins on web
This prototype allows service plugins to be loaded on web TSServer
Main changes:
- Adds a new host entryPoint called `importServicePlugin` for overriding how plugins can be loaded. This may be async
- Implement `importServicePlugin` for webServer
- The web server plugin implementation looks for a `browser` field in the plugin's `package.json`
- It then uses `import(...)` to load the plugin (the plugin source must be compiled to support being loaded as a module)
* use default export from plugins
This more or less matches how node plugins expect the plugin module to be an init function
* Allow configure plugin requests against any web servers in partial semantic mode
* Addressing some comments
- Use result value instead of try/catch (`ImportPluginResult`)
- Add awaits
- Add logging
* add tsserverWeb to patch in dynamic import
* Remove eval
We should throw instead when dynamic import is not implemented
* Ensure dynamically imported plugins are loaded in the correct order
* Add tests for async service plugin timing
* Update src/server/editorServices.ts
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Partial PR feedback
* Rename tsserverWeb to dynamicImportCompat
* Additional PR feedback
Co-authored-by: Ron Buckton <ron.buckton@microsoft.com>
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
Instead, search for stuff up the directory tree, with the main
functionality being to look for `Gulpfile.js` and assume the resulting
directory is the root.
(Unfortunatley, this is implemented twice, one in `scripts` and another
in `src`. It's not possible to use a single implementation for both
since that would require assuming a directory structure which this is
intended to avoid.)
Also, in `scripts/build/projects.js`, abstracdt common exec
functionality into a local helper, and use full paths based on the above
search instead of assuming relative paths assuming CWD being in the
project root.
Using shell-based execution is always a bad idea; this thing didn't do
that via an option, but instead did it manually by constructing a shell
command so it suffers from the same diseases.
Perhaps there was need for this at some point in the past, but things
are pretty robust now, so there's no need to avoid running the command
normally. The only thing that is needed is to add `which` which also
handles windows executable suffixes.
I tried this with a fresh clone on windows, where the tree and TS are
installed in paths that have spaces, and everything works as it should.
* Refactor emit substitution into transform
* Add reusable state machine for binary expressions
* Allow emitBinary to use state machine for comments/sourcemaps
* Switch core trampoline state back to arrays
* Switch binder to parallel stacks, temporarily partially revert emitBinary
* Add link to benchmark when posting perf results
* Ensure work stacks are per-execution
* Reenable comments and sourcemaps
* Remove playwright from package.json
* Install playwright on demand
* Adds debugging info to the playwright script
* Move installation first
* Get it working on node 10 again
* Update browserIntegrationTest.js
* Update browserIntegrationTest.js
Co-authored-by: Orta <git@orta.io>
* Copy typesMap.json in produceLKG.ts
It doesn't change very often and there's a hardcoded backup, but this
seems like a booby trap.
* Remove unused import
* Add deprecated related feature
* Add more support
* fix navtree
* Add identifier check
* Add more deprecated
* fix crash
* fix more crash
* fix crash
* improve diagnostic
* avoid new tag
* avoid tags
* accept baseline
* Check deprecated in binder
* fix baseline
* fix jsdoc cache
* fix incorrect fix
* Avoid useless changes
* Accept baseline
* Add tests
* fix perf
* fix public api
* Adjust deprecated mark on qualifed name
* Revolve alias symbol
* Use modifier flags insted of symbol props
* Fix modifier flag resolve
* Make lint happy
* Fix crash
* fix crash
* Add cached utils function
* Accept baseline
* Add more tests
* try pinning octokit again
* Avoid tests
* Use utils some
* Deprecated perf test (#3)
* check valueDeclaration only
* check without modifierFlags
* donot check alias
* use cached tag
* remove call to jsdoc
* use deprecated tag
* revert changes
* Revert mission changes
* use node flags
* cache result
* cache
* avoid modifier flags
* Opts
* fix jsdoc include modifier
* fix tests
* fix again
* use symbol flag
* set @octokit/rest back to latest
* fix trailing spacel int
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Adds puppeteer to test whether typescript.js runs in the browser
* Adds a check for the browser integration into the GitHub Actions CI
* Update to use playwright, and test in three browsers
Jake Bailey
Mateusz Burzyński
Ron Buckton
Jack Works
Matt Bierner
Ryan Cavanaugh
Alvin Ramskogler
uhyo
Andrew Branch
Eli Barzilay
Orta Therox
Oleksandr T
Ikko Ashimine
Wesley Wigham
Wesley Wigham
Andrew Casey
Wenlu Wang
Ethan Resnick
Nathan Shively-Sanders
Hye Sung Jung
Daniel Rosenwasser