This looks like a massive PR, but it's only a move from cli/tests ->
tests, and updates of relative paths for files.
This is the first step towards aggregate all of the integration test
files under tests/, which will lead to a set of integration tests that
can run without the CLI binary being built.
While we could leave these tests under `cli`, it would require us to
keep a more complex directory structure for the various test runners. In
addition, we have a lot of complexity to ignore various test files in
the `cli` project itself (cargo publish exclusion rules, autotests =
false, etc).
And finally, the `tests/` folder will eventually house the `test_ffi`,
`test_napi` and other testing code, reducing the size of the root repo
directory.
For easier review, the extremely large and noisy "move" is in the first
commit (with no changes -- just a move), while the remainder of the
changes to actual files is in the second commit.
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.
Code run within Deno-mode and Node-mode should have access to a
slightly different set of globals. Previously this was done through a
compile time code-transform for Node-mode, but this is not ideal and has
many edge cases, for example Node's globalThis having a different
identity than Deno's globalThis.
This commit makes the `globalThis` of the entire runtime a semi-proxy.
This proxy returns a different set of globals depending on the caller's
mode. This is not a full proxy, because it is shadowed by "real"
properties on globalThis. This is done to avoid the overhead of a full
proxy for all globalThis operations.
The globals between Deno-mode and Node-mode are now properly segregated.
This means that code running in Deno-mode will not have access to Node's
globals, and vice versa. Deleting a managed global in Deno-mode will
NOT delete the corresponding global in Node-mode, and vice versa.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Aapo Alasuutari <aapo.alasuutari@gmail.com>
This changes npm specifiers to be handled by deno_graph and resolved to
an npm package name and version when the specifier is encountered. It
also slightly changes how npm specifier resolution occurs—previously it
would collect all the npm specifiers and resolve them all at once, but
now it resolves them on the fly as they are encountered in the module
graph.
https://github.com/denoland/deno_graph/pull/232
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
