| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Before this PR, there would just be an uninformative "Error occurred"
message, after this PR you'll get a stack trace in the LSP output window
like this:
```text
Error during TS request "$getSupportedCodeFixes":
Error: i threw an exception
at serverRequest (ext:deno_tsc/99_main_compiler.js:1089:11)
```
|
|
cache when file is closed (#23517)
|
|
Doesn't have a noticeable perf impact from my benchmarking, but
theoretically should be better.
|
|
(#23451)
The actual handling of `$projectChanged` is quick, but JS requests are
not. The cleared caches only get repopulated on the next actual request,
so just batch the change notification in with the next actual request.
No significant difference in benchmarks on my machine, but this speeds
up `did_change` handling and reduces our total number of JS requests (in
addition to coalescing multiple JS change notifs into one).
|
|
|
|
Going through serde_v8 is slow, so just pass the args separately.
`op_resolve` is especially hot, so any speedups are good.
|
|
|
|
This PR enables V8 code cache for ES modules and for `require` scripts
through `op_eval_context`. Code cache artifacts are transparently stored
and fetched using sqlite db and are passed to V8. `--no-code-cache` can
be used to disable.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Our cjs tracking was a bit broken. It was marking stuff as esm that was
actually cjs leading to type checking errors.
|
|
I'm running into a node resolution bug in the lsp only and while
tracking it down I noticed this one.
Fixed by moving the project version out of `Documents`.
|
|
|
|
Previously we were deserializing it twice - once to `serde_json::Value`,
and then again from the `serde_json::Value` to a concrete type
|
|
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
Closes https://github.com/denoland/deno/issues/22113
Closes https://github.com/denoland/deno/issues/23177
Closes https://github.com/denoland/deno/issues/22883
Closes https://github.com/denoland/deno/issues/22377
|
|
|
|
Fixes the regression described in
https://github.com/denoland/deno/pull/23293#issuecomment-2049819724.
This affected jupyter notebooks, as the LSP was passing in already
denormalized specifiers, while the jupyter kernel was not. We need to
denormalize the specifiers to evict the proper keys from our caches.
|
|
Currently we evict a lot of the caches on the JS side of things on every
request, namely script versions, script file names, and compiler
settings (as of #23283, it's not quite every request but it's still
unnecessarily often).
This PR reports changes to the JS side, so that it can evict exactly the
caches that it needs too. We might want to do some batching in the
future so as not to do 1 request per change.
|
|
|
|
|
|
|
|
Closes #22786.
TLDR;
```jsonc
{
"tasks": {
// Some comment
//
// describing what the task does
"dev": "deno run -A --watch main.ts"
}
}
```
```bash
deno task
```
|
|
|
|
Fork PR: https://github.com/denoland/TypeScript/pull/10
Closes #23080
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds a way to connect to the TS compiler host that is run
as part of the "deno lsp" subcommand. This can be done by specifying
"DENO_LSP_INSPECTOR" variable.
---------
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
|
|
|
|
|
|
Adds performance measurements for all ops used by the LSP. Also changes
output of "Language server status" page to include more precise
information.
Current suspicion is that computing "script version" takes a long time
for some users.
|
|
Remove some dead code in "99_main_compiler.js". Eagerly start the LSP
TSC host, it was adding some not needed complexity around the TSC thread code.
|
|
for a directory, and TS files from JS extensions (#21464)
Adds an `--unstable-sloppy-imports` flag which supports the
following for `file:` specifiers:
* Allows writing `./mod` in a specifier to do extension probing.
- ex. `import { Example } from "./example"` instead of `import { Example
} from "./example.ts"`
* Allows writing `./routes` to do directory extension probing for files
like `./routes/index.ts`
* Allows writing `./mod.js` for *mod.ts* files.
This functionality is **NOT RECOMMENDED** for general use with Deno:
1. It's not as optimal for perf:
https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-2/
1. It makes tooling in the ecosystem more complex in order to have to
understand this.
1. The "Deno way" is to be explicit about what you're doing. It's better
in the long run.
1. It doesn't work if published to the Deno registry because doing stuff
like extension probing with remote specifiers would be incredibly slow.
This is instead only recommended to help with migrating existing
projects to Deno. For example, it's very useful for getting CJS projects
written with import/export declaration working in Deno without modifying
module specifiers and for supporting TS ESM projects written with
`./mod.js` specifiers.
This feature will output warnings to guide the user towards correcting
their specifiers. Additionally, quick fixes are provided in the LSP to
update these specifiers:
|
|
|
|
|
|
This commit changes the argument that "op_load" accepts, from
a serde struct to "&str". This should equal to a slightly better
performance.
|
|
|
|
This commit changes LSP log names by prefixing them, we now have these
prefixes:
- `lsp.*` - requests coming from the client
- `tsc.request.*` - requests coming from clients that are routed to TSC
- `tsc.op.*` - ops called by the TS host
- `tsc.host.*` - requests that call JavaScript runtime that runs
TypeScript compiler host
Additionall `Performance::mark` was split into `Performance::mark` and
`Performance::mark_with_args` to reduce verbosity of code and logs.
|
|
When an old request is obsoleted while the user is typing, the client
will say so to the server and tower-lsp will drop the future associated
with that request.
This wires that up to the ts server by having any request's token be
cancelled when the surrounding state is dropped.
|
|
This should help us get a better picture where most of the time is spent
(the TSC or the surrounding Rust code).
|
