Shows directory import and missing extension suggestions in error
messages similar but not exactly to node.
Closes #26802
Co-authored-by: Hajime-san <Hajime-san@users.noreply.github.com>
Fixes `gcp-metadata@6.1.1`
```
% deno eval "import 'npm:gcp-metadata@6.1.1'" # main
error: Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'GOOGLE_SDK_NODE_LOGGING')
at Object.log (file:///Users/divy/Library/Caches/deno/npm/registry.npmjs.org/google-logging-utils/0.0.2/build/src/logging-utils.js:356:36)
at Object.<anonymous> (file:///Users/divy/Library/Caches/deno/npm/registry.npmjs.org/gcp-metadata/6.1.1/build/src/index.js:52:20)
at Object.<anonymous> (file:///Users/divy/Library/Caches/deno/npm/registry.npmjs.org/gcp-metadata/6.1.1/build/src/index.js:409:4)
at Module._compile (node:module:745:34)
at loadMaybeCjs (node:module:770:10)
at Object.Module._extensions..js (node:module:755:12)
at Module.load (node:module:662:32)
at Function.Module._load (node:module:534:12)
at Module.require (node:module:681:19)
at require (node:module:812:16)
% target/debug/deno eval "import 'npm:gcp-metadata@6.1.1'" # this PR
```
---------
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
This makes it so imports of ambient modules (e.g. `$app/environment` in
svelte, any virtual module in vite, or other module provided by a
bundler) don't error in the LSP.
The way this works is that when we request diagnostics from TSC, we also
respond with the list of ambient modules. Then, in the diagnostics code,
we save diagnostics (produced by deno) that may be invalidated as an
ambient module and wait to publish the diagnostics until we've received
the ambient modules from TSC.
The actual ambient modules you get from TSC can contain globs, e.g.
`*.css`. So when we get new ambient modules, we compile them all into a
regex and check erroring imports against that regex. Ambient modules
should change rarely, so in most cases we should be using a pre-compiled
regex, which executes in linear time (wrt the specifier length).
TODO:
- Ideally we should only publish once, right now we publish with the
filtered specifiers and then the TSC ones
- deno check (#27633)
1. Allows resolving to `.ts` files for type checking.
2. Probes for `.ts` files to use for type checking.
To emphasize, this is only for type checking.
Adds references and examples to the documentation of the URL properties
which surface here:
https://docs.deno.com/api/web/~/URL✅ `./tools/lint.js`
✅ `./tools/format.js`
---------
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
Fixes https://github.com/denoland/deno/issues/24864
Need to add some tests, also unsure about the right counter size (went
with 128 bit to be safe)
---------
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
This PR resolves 2 issues of Socket class of node compat (both are
related to playwright)
Currently `browser.launch()` of playwright is not working.
`browser.launch` opens PipeTransport (which is based on Pipe/IPC socket)
with the browser process. But that pipe doesn't start reading the data
because of the workaround #27662 (which pauses the socket at the
beginning if it's from playwright-core). This PR fixes this issue by
checking whether the given handle is `ipc` handle or not.
Another issue is that sock-init-workaround for TLS connection stopped
working at #27707 because of the changes of TLS socket initialization
steps. This change fixes the issue by correctly returning the function
in workaround path.
The added case `specs::npm::playwright_compat` checks both fixes with
actual playwright and playwright-core packages.
`browser.launch` issues
closes #16899
closes #27623
`https.request` issue
closes #27658
Extracted out of https://github.com/denoland/deno/pull/27838/files
Reduces some allocations by accepting either a pathbuf or url for the
referrer for resolution and returning either a pathbuf or url at the
end, which the caller can then convert into to their preferred state.
This is about 4% faster when still converting the final result to a url
and 6% faster when keeping the result as a path in a benchmark I ran.
This commit adds a simple HashMap cache to completion requests.
On a test project the time to compute completions went from 1200ms
to 75ms and the cache contained ~300 entries when 8000 completion
items were produced by the TSC.
This is a short-lived cache and is discarded once the completion
request is finished. In a follow up commits we could make it persist
between requests.
