| Age | Commit message (Collapse) | Author |
|---|
|
This is super flaky on new Mac ARM runner. Disabling for now to unblock
main branch.
|
|
|
|
This doesn't actually trigger the arm64 build job nightly yet. I'll do
that in a follow up.
|
|
|
|
property (#22179)
Closes https://github.com/denoland/deno/issues/22176 (see detail there)
|
|
Fixes #22166
|
|
|
|
|
|
|
|
(#22147)
It makes it easier to write a standalone bin target for `deno compile`
without pulling a lot of the tooling and tsc loader logic
|
|
|
|
Step 1 of the Rustification of sanitizers, which unblocks the faster
timers.
This replaces the resource sanitizer with a Rust one, using the new APIs
in deno_core.
|
|
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
This commit makes deprecation warnings less verbose by default.
Only a single warnings is issued per deprecated API use.
`DENO_VERBOSE_WARNINGS` env var can be provided to enable more detailed
logging for each use of API including a stack trace.
https://github.com/denoland/deno/assets/13602871/9c036c84-0044-4cb6-9c8e-deb641f43712
|
|
|
|
|
|
|
|
Closes https://github.com/denoland/deno/issues/22116
|
|
Regression caused by https://github.com/denoland/deno/pull/22072.
I added a relevant test so we don't regress again.
Fixes https://github.com/denoland/deno/issues/22115
|
|
No code changes -- just splitting 40_testing into three files and
removing a couple of unused lines of code.
|
|
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
Follow up to https://github.com/denoland/deno/pull/22040.
By mistake I forgot to disable "experimental decorators" in the LSP.
|
|
|
|
This reverts commit 971eb0e5e836cdeaaefc25b2bab4c6a6a9f8e213.
To unblock v1.40 release.
|
|
Bumped versions for 1.40.0
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This commit adds automatic expansion of "imports" field in "deno.json"
file.
If "npm:" or "jsr:" imports are encountered we automatically try to add
a "directory" remapping.
Previously users had to specify entries for both `foo` and `foo/` to be
able to import like
`import { symbol1 } from "foo";` and `import { symbol2 } from
"foo/some_file.js"`:
```
{
"imports": {
"foo": "npm:@foo/bar",
"foo/": "npm:/@foo/bar/",
}
```
With this change users can only add entry for `foo`:
```
{
"imports": {
"foo": "npm:@foo/bar",
}
```
The entry for `foo/` will be provided automatically.
Similarly if user provides "directory" remapping explicitly, we will not
overwrite it.
|
|
- `Deno.FsFile.dataSync` -> `Deno.FsFile.syncData`
- `Deno.FsFile.dataSyncSync` -> `Deno.FsFile.syncDataSync`
Also marks these APIs as unstable
|
|
|
|
|
|
For removal in Deno v2.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This reverts commit 930ce2087051b4e45b2026ce7a77c14360a6993f.
This is producing false-positives that are not actionable to users.
We're gonna address this in another release.
|
|
For removal in Deno v2. There are two issues:
1. Any script being run causes the output of `warnOnDeprecatedApi()` to
be printed, even when none of the `rid` properties are called.
2. `.rid` of these classes is used in multiple tests. I'm not sure how
to account for that. I thought of having `STDIN_RID`, and friends,
constants, whose values can be shared between the tests and the classes
themselves. Should we go with that or do something else?
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
For removal in Deno v2. I've also updated the deprecation of
`Deno.FsWatcher.return()`, which, to be clear, I'm not in favour of
deprecating. I mention this in #15499. Either way, it's safe to merge
this PR, then decide against the deprecation.
|
|
For removal in Deno v2.
|
|
`Deno.{futime,futimeSync}` (#22070)
For removal in Deno v2.
---------
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
- changed `Deno.UnsafeWindowSurface` typings from accepting
`Deno.UnsafePointerView` to `Deno.PointerValue`
- added width and height to `GPUCanvasConfiguration`
|
|
For removal in Deno v2.
|
|
Removes weird "frame like" characters and simplifies the output:
```
warning: Use of deprecated "Deno.isatty()" API. This API will be removed in Deno 2.
Stack trace:
at file:///Users/ib/dev/deno/foo.js:2:8
hint: Use `stdStream.isTerminal()` instead.
warning: Use of deprecated "Deno.isatty()" API. This API will be removed in Deno 2.
Stack trace:
at file:///Users/ib/dev/deno/foo.js:7:8
hint: Use `stdStream.isTerminal()` instead.
```
https://github.com/denoland/deno/assets/13602871/7a6e24bf-44ec-4dbf-ac96-2af1db9f2ab9
|
|
For removal in Deno v2.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
For removal in Deno 2.0.
|
|
Follow up to https://github.com/denoland/deno/pull/21939 that adds
deprecation warnings to more `Deno` APIs:
- `Deno.copy()`
- `Deno.iter()`
- `Deno.iterSync()`
- `new Deno.Buffer()`
- `Deno.readAll()`
- `Deno.readAllSync()`
- `Deno.writeAll()`
- `Deno.writeAllSync()`
- `Deno.FsWatcher.return`
- `Deno.serveHttp()`
- `Deno.metrics()`
---------
Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com>
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
|
|
|
|
This commit deprecates `window` global and adds deprecation
notice on each use of `window`.
We decided to proceed with removal of `window` global variable in Deno
2.0. There's a lot of code
in the wild that uses pattern like this:
```
if (typeof window !== "undefined) {
...
}
```
to check if the code is being run in browser. However, this check passes
fine in Deno and
most often libraries that do this check try to access some browser API
that is not available
in Deno, or use DOM APIs (which are also not available in Deno).
This situation has occurred multiple times already
and it's unfeasible to expect the whole ecosystem to migrate to new
check (and even if that
happened there's a ton of code that's already shipped and won't change).
The migration is straightfoward - replace all usages of `window` with
`globalThis` or `self`.
When Deno encounters use of `window` global it will now issue a warning,
steering users
towards required changes:
```
Warning
├ Use of deprecated "window" API.
│
├ This API will be removed in Deno 2.0. Make sure to upgrade to a stable API before then.
│
├ Suggestion: Use `globalThis` or `self` instead.
│
├ Suggestion: You can provide `window` in the current scope with: `const window = globalThis`.
│
└ Stack trace:
└─ at file:///Users/ib/dev/deno/foo.js:7:1
```
Ref https://github.com/denoland/deno/issues/13367.
|
|
This commit adds support for [TC39 Decorator
Proposal](https://github.com/tc39/proposal-decorators).
These decorators are only available in transpiled sources - ie.
non-JavaScript files (because of lack of support in V8).
This entails that "experimental TypeScript decorators" are not available
by default
and require to be configured, with a configuration like this:
```
{
"compilerOptions": {
"experimentalDecorators": true
}
}
```
Closes https://github.com/denoland/deno/issues/19160
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: crowlkats <crowlkats@toaxl.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
|
|
For removal in Deno v2.
|
|
For removal in Deno v2.
|
|
To align with other deprecations.
|
