| Age | Commit message (Collapse) | Author |
|---|
|
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 commits adds auto-discovery of "package.json" file when running
"deno run" and "deno task" subcommands. In case of "deno run" the
"package.json" is being looked up starting from the directory of the
script that is being run, stopping early if "deno.json(c)" file is found
(ie. FS tree won't be traversed "up" from "deno.json").
When "package.json" is discovered the "--node-modules-dir" flag is
implied, leading to creation of local "node_modules/" directory - we
did that, because most tools relying on "package.json" will expect
"node_modules/" directory to be present (eg. Vite). Additionally
"dependencies" and "devDependencies" specified in the "package.json"
are downloaded on startup.
This is a stepping stone to supporting bare specifier imports, but
the actual integration will be done in a follow up commit.
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
|
|
Makes the resolver required and prints a warning when vendoring and a
dynamic import can't be resolved.
Closes #16522
|
|
|
|
To fix reports of breakage from #17655
|
|
|
|
Closes #17640
|
|
|
|
(#17566)
Closes #17563
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
This commit changes handling of config file to enable
specifying "imports" and "scopes" objects effectively making
the configuration file an import map.
"imports" and "scopes" take precedence over "importMap" configuration,
but have lower priority than "--importmap" CLI flag.
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
built-in Node modules (#17519)
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
See https://github.com/denoland/deno_graph/pull/205 for more details.
|
|
The way the standalone mode handles the `--cert` flag is different to
all other modes. This is because `--cert` takes a path to the
certificate file, which is directly added to the root cert store; except
for compile mode, where its byte contents are stored in the standalone
metadata, and they are added to the root cert store after the
`ProcState` is created.
This change instead changes `Flags::ca_file` (an `Option<String>`) into
`Flags::ca_data`, which can represent a `String` file path or a
`Vec<u8>` with the certificate contents. That way, standalone mode can
create a `ProcState` whose root cert store alreay contains the
certificate.
This change also adds a tests for certificates in standalone mode, since
there weren't any before.
This refactor will help with implementing web workers in standalone mode
in the future.
|
|
|
|
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)
|
|
multiple places (#17410)
|
|
|
|
This commit changes signature of "deno_core::ModuleLoader::resolve" to pass
an enum indicating whether or not we're resolving a specifier for dynamic import.
Additionally "CliModuleLoader" was changes to store both "parent permissions" (or
"root permissions") as well as "dynamic permissions" that allow to check for permissions
in top-level module load an dynamic imports.
Then all code paths that have anything to do with Node/npm compat are now checking
for permissions which are passed from module loader instance associated with given
worker.
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
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.
|
|
|
|
Fixes #14630
|
|
This PR optimizes the code in the language server by performing less
cloning of data.
|
|
Yearly tradition of creating extra noise in git.
|
|
Closes https://github.com/denoland/deno/issues/17056
Closes https://github.com/denoland/deno/issues/17055
|
|
|
|
This commit fixes "Add all missing imports" quick fix; before
it was replacing all occurrences with the same specifier. Now
every line returned from TSC is processed individually.
|
|
Closes #11897
|
|
|
|
Closes #17054.
The fallback is `Test lineNumber:columnNumber`
|
|
|
|
|
|
declaration (#17097)
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
Updated from: https://github.com/denoland/TypeScript/pull/2
|
|
had no types entry (#16958)
Closes #16957
|
|
Closes #15650
|
|
|
|
It seems we don't really need to allow these clippy rules.
|
|
requirements (#16866)
Closes #16867
|
