Adds a `DENO_PERMISSIONS_AUDIT` env var to set the path for a JSONL
permission audit log, with contains the permission and value.
Additionally this can be combined with `DENO_TRACE_PERMISSIONS`, which
will then include the traces in the audit log too.
Lint rule that's enabled by default in a workspace (when there's a
deno.json or package.json) in order to encourage using bare specifiers
and storing dependencies in a single place in the config file.
This is to help make this feature less ambiguous with `npm patch`, which
it's not like.
Note: the "patch" property will continue to work for the time being, but
the lockfile will have a bit of churn for this unstable property. We're
going to merge this in a patch because this feature is unstable.
Not sure what our handling of unstable properties in `deno.json` is.
This PR adds it to the config schema.
---------
Signed-off-by: Marvin Hagemeister <marvinhagemeister50@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit adds an unstable lint plugin API.
Plugins are specified in the `deno.json` file under
`lint.plugins` option like so:
```
{
"lint": {
"plugins": [
"./plugins/my-plugin.ts",
"jsr:@deno/lint-plugin1",
"npm:@deno/lint-plugin2"
]
}
}
```
The API is considered unstable and might be subject
to changes in the future.
Plugin API was modelled after ESLint API for the
most part, but there are no guarantees for compatibility.
The AST format exposed to plugins is closely modelled
after the AST that `typescript-eslint` uses.
Lint plugins use the visitor pattern and can add
diagnostics like so:
```
export default {
name: "lint-plugin",
rules: {
"plugin-rule": {
create(context) {
return {
Identifier(node) {
if (node.name === "a") {
context.report({
node,
message: "should be b",
fix(fixer) {
return fixer.replaceText(node, "_b");
},
});
}
},
};
},
},
},
} satisfies Deno.lint.Plugin;
```
Besides reporting errors (diagnostics) plugins can provide
automatic fixes that use text replacement to apply changes.
---------
Co-authored-by: Marvin Hagemeister <marvin@deno.com>
Co-authored-by: David Sherret <dsherret@gmail.com>
This PR updates `deno_lint` which contains a couple of bug fixes for
JSX/React related rules. The react rules now have all a `react-*` prefix
in the name as well.
This commit provides schema files for lint rules and lint tags
in this repo instead of pulling them from `deno_lint` repository.
A unit test was added to ensure all available rules are listed
in the schema file. A unit test for tags can be done once
https://github.com/denoland/deno/pull/27162 lands.
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 "dependencies" in `deno task` subcommand:
```jsonc
{
"tasks": {
"build": "deno run -RW build.ts",
"generate": "deno run -RW generate.ts",
"serve": {
"command": "deno run -RN server.ts",
"dependencies": ["build", "generate"]
}
}
}
```
Executing `deno task serve` will first execute `build` and `generate`
tasks (in parallel) and once both complete the `serve` task will be executed.
Number of tasks run in parallel is equal to the no of cores on the
machine, and respects `DENO_JOBS` env var if one is specified.
Part of https://github.com/denoland/deno/issues/26462
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Marvin Hagemeister <marvin@deno.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>
This PR adds a new `--unstable-node-globals` flag to expose Node globals
by default.
Fixes https://github.com/denoland/deno/issues/26611
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
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.
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`).
The long form "files" config has been flattened into the parent.
Old:
```json
{
"test": {
"files": {
"include": ["**/*.ts"],
"exclude": ["ignore.ts"]
}
}
}
```
New:
```json
{
"test": {
"include": ["**/*.ts"],
"exclude": ["ignore.ts"]
}
}
```
This was deprecated some time ago, but we're removing it now in Deno
2.0.
Closes#25415
The map field has been empty for years now and we don't want the emit
file to be exposed so it allows us to iterate on making the cache
faster. Additionally, it's racy/unreliable to rely on this information.
Instead, people should emit the TS files themselves using tools like
deno_emit, typescript, esbuild, etc.
Closes https://github.com/denoland/deno/issues/17703
The property names of the `exports` field in `deno.json` was never
validated. The `patternProperties` only validates values, whose property
name matches the regex. It doesn't validate the property names
themselves. That's what `propertyNames` is for.
Related https://github.com/denoland/deno/issues/25435
This adds object config for the workspace config:
```json
{
"workspace": {
"members": ["./member-1", "./member-2"]
}
}
```
This is a more verbose version of `"workspace": ["./member-1",
"./member-2"]`. Although we don't need it at the moment, it makes the
naming of `"workspace"` more clear and leaves the object open for more
config in the future.
Closes https://github.com/denoland/deno/issues/24456
Adds much better support for the unstable Deno workspaces as well as
support for npm workspaces. npm workspaces is still lacking in that we
only install packages into the root node_modules folder. We'll make it
smarter over time in order for it to figure out when to add node_modules
folders within packages.
This includes a breaking change in config file resolution where we stop
searching for config files on the first found package.json unless it's
in a workspace. For the previous behaviour, the root deno.json needs to
be updated to be a workspace by adding `"workspace":
["./path-to-pkg-json-folder-goes-here"]`. See details in
https://github.com/denoland/deno_config/pull/66Closes#24340Closes#24159Closes#24161Closes#22020Closes#18546Closes#16106Closes#24160
