Merging as a fix so that LTS gets this as it's a useful diagnostic tool.
The 1MB unique is because we deduplicate files that we store (ex. some
packages have the same file multiple times so we store that once).
I ended up changing the file system implementation to determine
its root directory as the last step of building it instead of being the
first step which makes it much more reliable.
split up otel config into user configurable and runtime configurable
parts. user configurable part is now set via env vars parsed according
to the otel spec. otel is now enabled via `OTEL_DENO=true`, and
`--unstable-otel` only acts as a guard.
Fixes: https://github.com/denoland/deno/issues/27273
Currently deno eagerly caches all npm packages in the workspace's npm
resolution. So, for instance, running a file `foo.ts` that imports
`npm:chalk` will also install all dependencies listed in `package.json`
and all `npm` dependencies listed in the lockfile.
This PR refactors things to give more control over when and what npm
packages are automatically cached while building the module graph.
After this PR, by default the current behavior is unchanged _except_ for
`deno install --entrypoint`, which will only cache npm packages used by
the given entrypoint. For the other subcommands, this behavior can be
enabled with `--unstable-npm-lazy-caching`
Fixes #25782.
---------
Signed-off-by: Nathan Whitaker <17734409+nathanwhit@users.noreply.github.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
This resurrects the `--unstable-detect-cjs` flag (which became stable),
and repurposes it to attempt loading .js/.jsx/.ts/.tsx files as CJS in
the following additional scenarios:
1. There is no package.json
1. There is a package.json without a "type" field
Also cleans up the implementation of this in the LSP a lot by hanging
`resolution_mode()` off `Document` (didn't think about doing that until
now).
Ensures a dynamic import in a CJS file will consider the referrer as an import for node resolution.
Also adds fixes (adds) support for `"resolution-mode"` in TypeScript.
Enhances the deno compile workflow for denort development by
automatically checking for a denort binary in the same directory as the
deno binary, provided both are located within a target/ directory. If
found, this denort binary will be used.
Key points:
- The DENORT_BIN environment variable remains supported for explicitly
specifying a custom denort binary path.
- Includes additional logic to verify if the deno binary is a symlink
pointing to an executable in the target/ directory.
---------
Signed-off-by: Ian Bull <irbull@gmail.com>
Support for Wasm modules.
Note this implements the standard where the default export is the
instance (not the module). The module will come later with source phase
imports.
```ts
import { add } from "./math.wasm";
console.log(add(1, 2));
```
```
> deno compile --allow-read=. --include data-file.txt main.js
```
This only applies to files on the filesystem. For remote modules, that's
going to have to wait for `import ... from "./data.txt" with { "type":
"bytes" }` or whatever it will be.
Adds a lazily created code cache to `deno compile` by default.
The code cache is created on first run to a single file in the temp
directory and is only written once. After it's been written, the code
cache becomes read only on subsequent runs. Only the modules loaded
during startup are cached (dynamic imports are not code cached).
The code cache can be disabled by compiling with `--no-code-cache`.
Closes #26425
## Overview
This PR adds support for specifying multiple environment files as
arguments when using the Deno CLI. Subsequent files override
pre-existing variables defined in previous files.
If the same variable is defined in the environment and in the file, the
value from the environment takes precedence.
## Example Usage
```bash
deno run --allow-env --env-file --env-file=".env.one" --env-file=".env.two" script.ts
```
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Improving the breadth of collected data, and ensuring that the collected
data is more likely to be successfully reported.
- Use `log` crate in more places
- Hook up `log` crate to otel
- Switch to process-wide otel processors
- Handle places that use `process::exit`
Also adds a more robust testing framework, with a deterministic tracing
setting.
Refs: https://github.com/denoland/deno/issues/26852
This will respect `"type": "commonjs"` in a package.json to determine if
`.js`/`.jsx`/`.ts`/.tsx` files are CJS or ESM. If the file is found to
be ESM it will be loaded as ESM though.
Initial import of OTEL code supporting tracing. Metrics soon to come.
Implements APIs for https://jsr.io/@deno/otel so that code using
OpenTelemetry.js just works tm.
There is still a lot of work to do with configuration and adding
built-in tracing to core APIs, which will come in followup PRs.
---------
Co-authored-by: Luca Casonato <hello@lcas.dev>
This PR fixes #24453, by introducing a ctime (using ctime for UNIX and
ChangeTime for Windows) to Deno.stats.
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
* cts support
* better cjs/cts type checking
* deno compile cjs/cts support
* More efficient detect cjs (going towards stabilization)
* Determination of whether .js, .ts, .jsx, or .tsx is cjs or esm is only
done after loading
* Support `import x = require(...);`
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes #26085.
Adds a basic retry utility with some defaults, starts off with a 100ms
wait, then 250ms, then 500ms
I've applied the retry in the http client, reusing an existing function,
so this also applies to retrying downloads of deno binaries in `upgrade`
and `compile`. I can make a separate function that doesn't retry so this
doesn't affect `upgrade` and `compile`, but it seemed desirable to have
retries there too, so I left it in.
When using the `--unstable-detect-cjs` flag or adding `"unstable":
["detect-cjs"]` to a deno.json, it will make a JS file CJS if the
closest package.json contains `"type": "commonjs"` and the file is not
an ESM module (no TLA, no `import.meta`, no `import`/`export`).
This replaces `--allow-net` for import permissions and makes the
security sandbox stricter by also checking permissions for statically
analyzable imports.
By default, this has a value of
`--allow-import=deno.land:443,jsr.io:443,esm.sh:443,raw.githubusercontent.com:443,gist.githubusercontent.com:443`,
but that can be overridden by providing a different set of hosts.
Additionally, when no value is provided, import permissions are inferred
from the CLI arguments so the following works because
`fresh.deno.dev:443` will be added to the list of allowed imports:
```ts
deno run -A -r https://fresh.deno.dev
```
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
