| Age | Commit message (Collapse) | Author |
|---|
|
|
|
1. Breaks up functionality within `ProcState` into several other structs
to break out the responsibilities (`ProcState` is only a data struct
now).
2. Moves towards being able to inject dependencies more easily and have
functionality only require what it needs.
3. Exposes `Arc<T>` around the "service structs" instead of it being
embedded within them. The idea behind embedding them was to reduce the
verbosity of needing to pass around `Arc<...>`, but I don't think it was
exactly working and as we move more of these structs to be more
injectable I don't think the extra verbosity will be a big deal.
|
|
Closes https://github.com/denoland/vscode_deno/issues/797
Closes https://github.com/denoland/deno/issues/11190
Closes https://github.com/denoland/vscode_deno/issues/811
Closes https://github.com/denoland/vscode_deno/issues/761
Closes https://github.com/denoland/vscode_deno/issues/585
Closes https://github.com/denoland/vscode_deno/issues/561
Closes https://github.com/denoland/vscode_deno/issues/410
|
|
CacheDB (#18469)
Fast-follow on #18401 -- the reason that some tests were panicking in
the `CacheDB` `impl Drop` was that the cache itself was being dropped
during panic and the runtime may or may not still exist at that point.
We can reduce the actual tokio runtime testing to where it's needed.
In addition, we return the journal mode to `TRUNCATE` to avoid the risk
of data corruption.
|
|
This gets SQLite off the flamegraph and reduces initialization time by
somewhere between 0.2ms and 0.5ms. In addition, I took the opportunity
to move all the cache management code to a single place and reduce
duplication. While the PR has a net gain of lines, much of that is just
being a bit more deliberate with how we're recovering from errors.
The existing caches had various policies for dealing with cache
corruption, so I've unified them and tried to isolate the decisions we
make for recovery in a single place (see `open_connection` in
`CacheDB`). The policy I chose was:
1. Retry twice to open on-disk caches
2. If that fails, try to delete the file and recreate it on-disk
3. If we fail to delete the file or re-create a new cache, use a
fallback strategy that can be chosen per-cache: InMemory (temporary
cache for the process run), BlackHole (ignore writes, return empty
reads), or Error (fail on every operation).
The caches all use the same general code now, and share the cache
failure recovery policy.
In addition, it cleans up a TODO in the `NodeAnalysisCache`.
|
|
These caused a bunch of unnecessary allocations on each startup.
|
|
cache (#18356)
|
|
Adds `--ext` to `deno run`, closes #5088
Additionally
- Adds `--ext` to `deno compile` and `deno bundle`
|
|
Disable Write-Ahead Log for the cached module source database.
This brings SQLite connection cost on startup from 2.5% to 1.6%.
|
|
(#18337)
…'t automatically re-created (#18330)"
This reverts commit 2ef8269fdb395b0736153ff5fbb9696cbb976e42.
Printing these messages by default (instead of requiring `-L debug`
flag) caused
various tests to start printing it and mismatch in output assertions.
|
|
automatically re-created (#18330)
|
|
|
|
These methods are confusing because the arguments are backwards. I feel
like they should have never been added to `Option<T>` and that clippy
should suggest rewriting to
`map(...).unwrap_or(...)`/`map(...).unwrap_or_else(|| ...)`
https://github.com/rust-lang/rfcs/issues/1025
|
|
This lazily does an "npm install" when any package name matches what's
found in the package.json or when running a script from package.json
with deno task.
Part of #17916
Closes #17928
|
|
language server (#17891)
|
|
This commit enables resolution of "bare specifiers" (eg. "import express
from 'express';") if a "package.json" file is discovered.
It's a step towards being able to run projects authored for Node.js
without any changes.
With this commit we are able to successfully run Vite projects without
any changes to the user code.
---------
Co-authored-by: David Sherret <dsherret@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>
|
|
This PR fixes peer dependency resolution to only resolve peers based on
the current graph traversal path. Previously, it would resolve a peers
by looking at a graph node's ancestors, which is not correct because
graph nodes are shared by different resolutions.
It also stores more information about peer dependency resolution in the
lockfile.
|
|
This PR changes Node.js/npm compatibility layer to use polyfills for
built-in Node.js
embedded in the snapshot (that are coming from "ext/node" extension).
As a result loading `std/node`, either from
"https://deno.land/std@<latest>/" or
from "DENO_NODE_COMPAT_URL" env variable were removed. All code that is
imported via "npm:" specifiers now uses code embedded in the snapshot.
Several fixes were applied to various modules in "ext/node" to make
tests pass.
---------
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
|
|
Micro optimization because these allocations were coming up on a flame
graph I was looking at (only 0.28% of total).
|
|
|
|
Just some watcher init step that I thought would be "cloned over" but
needs to be done again on reset.
|
|
(#15466) (#17591)
This reverts commit 3545bff678f20c3fdf17fe6b26f96cf1b74f917c.
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
Closes https://github.com/denoland/deno/issues/2699
Closes https://github.com/denoland/deno/issues/2347
Uses unstable rustfmt features. Since dprint invokes `rustfmt` we do not
need to switch the cargo toolchain to nightly. Do we care about
formatting stability of our codebase across Rust versions? (I don't)
|
|
|
|
This commit changes "ProcState" to store "file_fetcher" field in an "Arc",
allowing it to be preserved between restarts and thus keeping the state
alive between the restarts. File watchers for "deno test" and "deno bench"
now reset "ProcState" between restarts.
|
|
mutability (#17134)
Turns out we were cloning permissions which after prompting were discarded,
so the state of permissions was never preserved. To handle that we need to store
all permissions behind "Arc<Mutex<>>" (because there are situations where we
need to send them to other thread).
Testing and benching code still uses "Permissions" in most places - it's undesirable
to share the same permission set between various test/bench files - otherwise
granting or revoking permissions in one file would influence behavior of other test
files.
|
|
Yearly tradition of creating extra noise in git.
|
|
|
|
|
|
cache folder (#16857)
|
|
|
|
not debug (#16689)
|
|
|
|
This commit adds a cache for CJS and ESM analysis that is backed by an
SQLite file.
The connection to the DB is lazily created on first use, so shouldn't
have impact on the startup time.
Benched with running Vite
Deno v1.26:
```
$ deno task dev
Warning deno task is unstable and may drastically change in the future
Task dev deno run -A --unstable --node-modules-dir npm:vite
VITE v3.1.4 ready in 961 ms
➜ Local: http://localhost:5173/
➜ Network: use --host to expose
```
This branch:
```
../deno/target/release/deno task dev
Warning deno task is unstable and may drastically change in the future
Task dev deno run -A --unstable --node-modules-dir npm:vite
VITE v3.1.4 ready in 330 ms
➜ Local: http://localhost:5173/
➜ Network: use --host to expose
```
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
Closes #15612
|
|
memory (#15502)
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
