The `PropertyDefinition` node also allows `PrivateIdentifier` as a type
for the `key`. Example:
```ts
class Foo {
#foo = 2;
}
```
Fixes one issue reported in
https://github.com/denoland/deno/issues/28355
Adding examples to the JSDocs for createImageBitmap and
formatting/linting file
---------
Co-authored-by: Phil Hawksworth <phil@deno.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes https://github.com/denoland/deno/issues/27569.
Fixes https://github.com/denoland/deno/issues/27215.
This PR makes it so type resolution falls back to looking for definitely
typed packages (`@types/foo`) if a given NPM package does not contain
type declarations.
One complication is choosing _which_ version of the `@types/*` package
to use, if the project depends on multiple versions. The heuristic here
is to try to match the major and minor versions, falling back to the
latest version. So if you have
```
@types/foo: 0.1.0, 0.2.0, 3.1.0, 3.1.2, 4.0.0
foo: 3.1.0
```
we would choose `@types/foo@3.1.2` when resolving types for `foo`.
---
Note that this only uses `@types/` packages if you _already_ depend on
them. So a follow up to this PR could be to add a diagnostic and
quickfix to install `@types/foo` if we don't find types for `foo`.
This commits moves all `.d.ts` files from `ext/*` to `cli/tsc/dts`.
Due to TSC snapshot removal, `cargo publish` is now erroring out,
unable to find the declaration files. These files were moved to
"cli/tsc/dts", because it's much easier than keeping them in
extension directories, while still providing them compressed
or uncompressed depending on the build type.
In particular this helps startup of the TSC isolate because
`00_typescript.js` can use the code cache.
Overall, this offsets a fair bit of the hit we took when we removed the
TSC snapshot.
```
❯ hyperfine --warmup 5 -p "rm -rf ~/Library/Caches/deno/check_cache_v2" "./deno-this-pr check main.ts" "./deno-no-snapshot check main.ts" "./deno-with-snapshot check main.ts"
Benchmark 1: ../../deno/target/release-lite/deno check main.ts
Time (mean ± σ): 145.7 ms ± 3.6 ms [User: 347.6 ms, System: 36.9 ms]
Range (min … max): 142.2 ms … 155.9 ms 19 runs
Benchmark 2: ./deno-no-snapshot check main.ts
Time (mean ± σ): 195.4 ms ± 3.3 ms [User: 397.7 ms, System: 34.9 ms]
Range (min … max): 192.1 ms … 206.0 ms 15 runs
Benchmark 3: ./deno-with-snapshot check main.ts
Time (mean ± σ): 109.0 ms ± 2.2 ms [User: 155.9 ms, System: 19.3 ms]
Range (min … max): 106.5 ms … 118.0 ms 26 runs
Summary
./deno-with-snapshot check main.ts ran
1.34 ± 0.04 times faster than ./deno-this-pr check main.ts
1.79 ± 0.05 times faster than ./deno-no-snapshot check main.ts
```
adds tracing and opentelemetry exporting to the LSP.
enable it in `.vscode/settings.json` (or wherever you configure the
LSP), like
```
{
"deno.tracing": true
}
```
which will by default export opentelemetry traces to `localhost:4317`
or
```
{
"deno.tracing": {
// all fields optional
"collector": "openTelemetry" (default) | "logging" (output in lsp log window)
"collectorEndpoint": "http://localhost:4318" (for opentelemetry)
"enable": true | false,
"filter": "info" // defaults to "info", but can be any span filter
}
}
```
---
a full working setup would be
1: Run jaeger (an opentelemetry collector with a nice UI):
```
docker run --rm -p 16686:16686 -p 4317:4317 jaegertracing/jaeger
```
2. Enable in .vscode/settings.json
```
{
"deno.tracing": true
}
```
3. Restart LSP (right now it only will start the opentelemetry exporter
on LSP startup)
3. open `http://localhost:16686` in your browser
---------
Co-authored-by: Nathan Whitaker <nathan@deno.com>
This commit changes the TS host implementation
in the LSP to use the same snapshot as the runtime worker
and web worker use.
This is due to upcoming V8 upgrade that might require
that all isolates in the same process use the exact same
snapshot.
Removes the TSC snapshot to unblock the V8 upgrade (which enables shared
RO heap, and is incompatible with multiple snapshots).
this compresses the sources and declaration files as well, which leads
to a roughly 4.2MB reduction in binary size.
this currently adds about 80ms to deno check times, but code cache isn't
wired up for the extension code (namely `00_typescript.js`) yet
```
❯ hyperfine --warmup 5 -p "rm -rf ~/Library/Caches/deno/check_cache_v2" "../../deno/target/release-lite/deno check main.ts" "deno check main.ts"
Benchmark 1: ../../deno/target/release-lite/deno check main.ts
Time (mean ± σ): 184.2 ms ± 2.2 ms [User: 378.3 ms, System: 48.2 ms]
Range (min … max): 181.5 ms … 189.9 ms 15 runs
Benchmark 2: deno check main.ts
Time (mean ± σ): 107.4 ms ± 1.2 ms [User: 155.3 ms, System: 23.9 ms]
Range (min … max): 105.3 ms … 109.6 ms 26 runs
Summary
deno check main.ts ran
1.72 ± 0.03 times faster than ../../deno/target/release-lite/deno check main.ts
```
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit adds an unstable lint plugin API.
Plugins are specified in the `deno.json` file under
`lint.plugins` option like so:
```
{
"lint": {
"plugins": [
"./plugins/my-plugin.ts",
"jsr:@deno/lint-plugin1",
"npm:@deno/lint-plugin2"
]
}
}
```
The API is considered unstable and might be subject
to changes in the future.
Plugin API was modelled after ESLint API for the
most part, but there are no guarantees for compatibility.
The AST format exposed to plugins is closely modelled
after the AST that `typescript-eslint` uses.
Lint plugins use the visitor pattern and can add
diagnostics like so:
```
export default {
name: "lint-plugin",
rules: {
"plugin-rule": {
create(context) {
return {
Identifier(node) {
if (node.name === "a") {
context.report({
node,
message: "should be b",
fix(fixer) {
return fixer.replaceText(node, "_b");
},
});
}
},
};
},
},
},
} satisfies Deno.lint.Plugin;
```
Besides reporting errors (diagnostics) plugins can provide
automatic fixes that use text replacement to apply changes.
---------
Co-authored-by: Marvin Hagemeister <marvin@deno.com>
Co-authored-by: David Sherret <dsherret@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)
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.
