Working on loading plugin configuration for
https://github.com/denoland/deno/pull/27203
I encountered a lot of complexity, so did some drive-by cleanups to make
it easier to grok the code and have fewer duplicate names.
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>
Extracting out more code from the CLI for reuse elsewhere (still more
work to do, but this is a start).
This is the code for extracting npm tarballs and saving information in
the npm cache in the global deno_dir.
This commit adds support for understanding "workpace:^"
and "workspace:~" version constraints in npm/pnpm workspaces.
This is done by upgrading various crates to their latest versions.
Closes https://github.com/denoland/deno/issues/26726
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
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).
This commit adds support for `deno init --npm <package>`.
Running this will actually call to `npm:create-<package>` package that
is equivalent to running `npm create <package>`.
User will be prompted if they want to allow all permissions and
lifecycle scripts to be executed.
Closes https://github.com/denoland/deno/issues/26461
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: crowlkats <crowlkats@toaxl.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
This commit adds workspace support to "deno taks".
Two new flags were added:
- "--recursive" - allows to run a specified task in workspace members,
eg. "deno task --recursive dev"
- "--filter" - allows to run a specified task only in specific workspace members,
eg. "deno task --recursive --filter 'client/*' dev"
"--filter" flag implies "--recursive" flag.
Closes https://github.com/denoland/deno/issues/24991
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Signed-off-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Nathan Whitaker <17734409+nathanwhit@users.noreply.github.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: David Sherret <dsherret@gmail.com>
Closes #20487
Currently spelled
```
deno outdated
```
and
```
deno outdated --update
```
Works across package.json and deno.json, and in workspaces.
There's a bit of duplicated code, I'll refactor to reduce this in follow
ups
## Currently supported:
### Printing outdated deps (current output below which basically mimics
pnpm, but requesting feedback / suggestions)
```
deno outdated
```
### Updating deps
semver compatible:
```
deno outdated --update
```
latest:
```
deno outdated --latest
```
current output is basic, again would love suggestions
#### Filters
```
deno outdated --update "@std/*"
deno outdated --update --latest "@std/* "!@std/fmt"
```
#### Update to specific versions
```
deno outdated --update @std/fmt@1.0.2 @std/cli@^1.0.3
```
### Include all workspace members
```
deno outdated --recursive
deno outdated --update --recursive
```
## Future work
- interactive update
- update deps in js/ts files
- better support for transitive deps
Known issues (to be fixed in follow ups):
- If no top level dependencies have changed, we won't update transitive
deps (even if they could be updated)
- Can't filter transitive deps, or update them to specific versions
## TODO (in this PR):
- ~~spec tests for filters~~
- ~~spec test for mixed workspace (have tested manually)~~
- tweak output
- suggestion when you try `deno update`
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit improves permission prompts by adding an option
to print a full trace of where the permissions is being requested.
Due to big performance hint of stack trace collection, this is only
enabled when `DENO_TRACE_PERMISSIONS` env var is present.
Closes https://github.com/denoland/deno/issues/20756
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit adds `--eval` flag to `deno task` subcommand.
This flag allows to evaluate provided "task name" as a task itself,
effectively allowing to use `deno_task_shell` from the command line.
Also fixes shebang parsing for `node_modules/.bin/` entries to handle
`#!/usr/bin/node -S node` in addition to `#!/usr/bin/node node`.
Closes https://github.com/denoland/deno/issues/26918
We should track dependencies in `jsxImportSource`,
`jsxImportSourceTypes`, and `types`.
That way, for example, if someone removes or changes the
`jsxImportSource` then we can remove those items from the lockfile.
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>
This commit changes three aspects of `deno task`:
1. Tasks can now be written using object notation like so:
```jsonc
{
"tasks": {
"foo": "deno run foo.js",
"bar": {
"command": "deno run bar.js"
}
}
```
2. Support for comments for tasks is now removed. Comments above tasks
will
no longer be printed when running `deno task`.
3. Tasks written using object notation can have "description" field that
replaces
support for comments above tasks:
```jsonc
{
"tasks": {
"bar": {
"description": "This is a bar task"
"command": "deno run bar.js"
}
}
```
```
$ deno task
Available tasks:
- bar
// This is a bar task
deno run bar.js
```
Pulled most of the changes from
https://github.com/denoland/deno/pull/26467 to
support "dependencies" in tasks. Additionally some cleanup was performed
to make code easier to read.
---------
Co-authored-by: David Sherret <dsherret@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>
* 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>
This PR addresses issue #25600
Changes:
Updated `fn has_hmr` to check `serve` subcommand and return its hmr
value if found, in order to run the worker in serve mode with
hmr_runner. Thus the hmr event can be dispatched upon changes on the
file served.
Some `deno add` and `deno install` example usage commands didn't have
the `jsr:` or `npm:` prefixes.
---------
Signed-off-by: Marvin Hagemeister <marvinhagemeister50@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This change removes the handling of `--check` and `--no-check` flags from
`deno repl` subcommand.
Currently these flags don't have effects, and the help output for these
options are incorrect and confusing.
closes #26042
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`).
