| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
Instead of using the default 1.4Gb limit (which was meant for browser
tabs) configure V8 to
set the heap limit to the amount of memory available in the system.
Closes https://github.com/denoland/deno/issues/23424
Closes https://github.com/denoland/deno/issues/26435
Closes https://github.com/denoland/deno/issues/21226
|
|
package.json (#26439)
This will respect `"type": "commonjs"` in a package.json to determine if
`.js`/`.jsx`/`.ts`/.tsx` files are CJS or ESM. If the file is found to
be ESM it will be loaded as ESM though.
|
|
|
|
* cts support
* better cjs/cts type checking
* deno compile cjs/cts support
* More efficient detect cjs (going towards stabilization)
* Determination of whether .js, .ts, .jsx, or .tsx is cjs or esm is only
done after loading
* Support `import x = require(...);`
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Bedis Nbiba <bedisnbiba@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Gets rid of WorkspaceMemberContext. It's now `Workspace` and
`WorkspaceDirectory`
- Uses the workspace cache in the lsp
* https://github.com/denoland/deno_config/pull/95
* https://github.com/denoland/deno_config/pull/96
|
|
Makes the lsp use the same code as the rest of the cli.
|
|
(#24492)
Closes #16370
|
|
Adds much better support for the unstable Deno workspaces as well as
support for npm workspaces. npm workspaces is still lacking in that we
only install packages into the root node_modules folder. We'll make it
smarter over time in order for it to figure out when to add node_modules
folders within packages.
This includes a breaking change in config file resolution where we stop
searching for config files on the first found package.json unless it's
in a workspace. For the previous behaviour, the root deno.json needs to
be updated to be a workspace by adding `"workspace":
["./path-to-pkg-json-folder-goes-here"]`. See details in
https://github.com/denoland/deno_config/pull/66
Closes #24340
Closes #24159
Closes #24161
Closes #22020
Closes #18546
Closes #16106
Closes #24160
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
partially fixing https://github.com/denoland/deno/issues/23820
https://github.com/denoland/deno/assets/41257923/0adb5d4e-cfd5-4195-9045-19d1c0a07a43
BTW, it is out of scope on this PR that to process type of `@param` to
be an code block due to it's a bit complicated.
|
|
We were wrapping the display string in an unnecessary pair of triple
backticks, breaking highlighting
Before:
After:
|
|
|
|
|
|
|
|
|
|
Closes #23688
|
|
|
|
Fixes the `Debug Failure` errors described in
https://github.com/denoland/deno/issues/23643#issuecomment-2094552765 .
The issue here was that we were passing diagnostic codes as strings but
TSC expects the codes to be numbers. This resulted in some quick fixes
not working (as illustrated by the test added here which fails before
this PR).
The first commit is the actual fix. The rest are just test related.
|
|
|
|
result upon cancellation (#23645)
Fixes #23643.
We weren't catching the cancellation exception thrown by TSC on the JS
side, so the rust side was catching this exception and then attempting
to print out the exception via `toString`. That last bit resulted in a
cryptic `[object Object]` showing up in the logs like so:
```
Error during TS request "getCompletionEntryDetails":
[object Object]
```
I'm not 100% sure how we weren't seeing this in the past. My guess is
that #23409 and the subsequent PR to improve the exception catching and
logging surfaced this, but I'm still not quite clear on it.
My initial fix here returned `null` to rust when a server request was
cancelled, but this resulted in a deserialization error when we
attempted to deserialize that into the expected response type. So now,
as soon as the request's cancellation token signals we'll stop waiting
for a response and return an error (which will get swallowed as the LSP
request is being cancelled).
I was a bit surprised to find that [this
branch](https://github.com/nathanwhit/deno/blob/0c671c9792ac706c1ecd60f88efdc5eb8e941917/cli/lsp/tsc.rs#L1093)
actually executes sometimes, I believe due to the fact that aborting a
future may not [immediately stop its
execution](https://docs.rs/futures/latest/futures/stream/struct.AbortHandle.html#method.abort).
|
|
This reverts commit 5cae3439912ad60eb2866f3d4372a5fe4d0de957.
Caused a +3.3s regression in one of the LSP benchmarks at
deno.land/benchmarks.
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
