| Age | Commit message (Collapse) | Author |
|---|
|
This initially uses the new diagnostic printer in `deno lint`,
`deno doc` and `deno publish`. In the limit we should also update
`deno check` to use this printer.
|
|
|
|
This upgrade unblocks support for ES decorator proposal.
Co-authored-by: crowlkats <crowlkats@toaxl.com>
|
|
|
|
This commit adds "UnstableConfig" struct which centralizes
handling of all "--unstable-*" flags.
Closes https://github.com/denoland/deno/issues/21920
|
|
This commit removes the requirement for `--unstable` flag in `deno
jupyter` subcommand. The process will no longer exit if this flag is not
provided, however the subcommand itself is still considered unstable
and might change in the future.
Required for https://github.com/denoland/deno/pull/21452
|
|
~~Waiting on: https://github.com/denoland/deno_config/pull/31~~
Closes #21971
Closes https://github.com/denoland/vscode_deno/issues/1029
|
|
|
|
|
|
This commit removes conditional type-checking of unstable APIs.
Before this commit `deno check` (or any other type-checking command and
the LSP) would error out if there was an unstable API in the code, but not
`--unstable` flag provided.
This situation hinders DX and makes it harder to configure Deno. Failing
during runtime unless `--unstable` flag is provided is enough in this case.
|
|
Closes #21926
|
|
|
|
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
`"nodeModulesDir": false` (#21858)
There's no need to auto-install the package.json if the user is not
using a node_modules directory.
Closes #21850
|
|
|
|
We were calling `expand_glob` on our excludes, which is very expensive
and unnecessary because we can pattern match while traversing instead.
1. Doesn't expand "exclude" globs. Instead pattern matches while walking
the directory.
2. Splits up the "include" into base paths and applicable file patterns.
This causes less pattern matching to occur because we're only pattern
matching on patterns that might match and not ones in completely
unrelated directories.
|
|
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
Some drive-by cleanup as I'm working through
https://github.com/denoland/deno_core/pull/415.
|
|
I did not measure this change (O(n) to O(log n)), but mainly this should
be slightly more accurate at getting the line number.
|
|
being on PATH (#21767)
We were failing silently in this scenario.
|
|
|
|
|
|
|
|
Main change is that:
- "hyper" has been renamed to "hyper_v014" to signal that it's legacy
- "hyper1" has been renamed to "hyper" and should be the default
|
|
|
|
Left behind in #21623 by mistake.
|
|
This commit fixes a panic in `deno coverage` command if the file
to be covered doesn't produce any coverage data.
Fixes https://github.com/denoland/deno/issues/21580
|
|
Just removing some duplicated code.
|
|
Added group banner to bench output.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Luca Casonato <lucacasonato@yahoo.com>
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sloppily (#21506)
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
One warning for when using it with `deno compile` and another when using
it with `deno run`.
|
|
|
|
for a directory, and TS files from JS extensions (#21464)
Adds an `--unstable-sloppy-imports` flag which supports the
following for `file:` specifiers:
* Allows writing `./mod` in a specifier to do extension probing.
- ex. `import { Example } from "./example"` instead of `import { Example
} from "./example.ts"`
* Allows writing `./routes` to do directory extension probing for files
like `./routes/index.ts`
* Allows writing `./mod.js` for *mod.ts* files.
This functionality is **NOT RECOMMENDED** for general use with Deno:
1. It's not as optimal for perf:
https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-2/
1. It makes tooling in the ecosystem more complex in order to have to
understand this.
1. The "Deno way" is to be explicit about what you're doing. It's better
in the long run.
1. It doesn't work if published to the Deno registry because doing stuff
like extension probing with remote specifiers would be incredibly slow.
This is instead only recommended to help with migrating existing
projects to Deno. For example, it's very useful for getting CJS projects
written with import/export declaration working in Deno without modifying
module specifiers and for supporting TS ESM projects written with
`./mod.js` specifiers.
This feature will output warnings to guide the user towards correcting
their specifiers. Additionally, quick fixes are provided in the LSP to
update these specifiers:
|
