1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-14 03:23:17 -05:00
Commit graph

53 commits

Author SHA1 Message Date
Nathan Whitaker
c371b2a492
fix(install): re-setup bin entries after running lifecycle scripts (#26752)
Fixes #26677

Some packages (like supabase) declare bin entries that don't exist until
lifecycle scripts are run. For instance, the lifecycle script downloads
a binary file which serves as a bin entrypoint.

Unfortunately you can't just defer setting up the bin entries until
after lifecycle scripts have run, because the scripts may rely on them.

I looked into this, and PNPM just re-links bin entries after running
lifecycle scripts. I think that's about the best we can do as well.

Note that we'll only re-setup bin entries for packages whose lifecycle
scripts we run. This should limit the performance cost, as typically a
given project will not have many lifecycle scripts (and of those, many
of them probably don't have bin entries to set up).
2024-11-12 09:23:39 -08:00
Nathan Whitaker
f9a05068d6
fix(install): handle invalid function error, and fallback to junctions regardless of the error (#26730)
Fixes #26116.

Handle the new error and treat is as lacking permission to make
symlinks, but also to make this more robust, just always fall back to
junctions no matter what the actual error is. Instead, warn if the error
isn't one we've handled, but go on to attempt creating the junction
2024-11-05 04:16:53 +00:00
David Sherret
826e42a5b5
fix: improved support for cjs and cts modules (#26558)
* 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>
2024-11-01 12:27:00 -04:00
Nathan Whitaker
7a990d9d42
feat(npm): support --allow-scripts on deno run (and deno add, deno test, etc) (#26075)
Fixes https://github.com/denoland/deno/issues/25533. Fixes
https://github.com/denoland/deno/issues/25396.

Previously we only supported it on `deno install` and `deno cache`,
which is annoying if you're using `nodeModulesDir: auto`.

Also changes from printing output of lifecycle scripts directly to
capturing the output and only printing it on error.
2024-10-12 12:14:32 -07:00
David Sherret
2de4faa483
refactor: improve node permission checks (#26028)
Does less work when requesting permissions with `-A`
2024-10-04 20:55:41 +01:00
Nathan Whitaker
275418473e
fix(install): store tags associated with package in node_modules dir (#26000)
Fixes #25998. Fixes https://github.com/denoland/deno/issues/25928.

Originally I was just going to make this an error message instead of a
panic, but once I got to a minimal repro I felt that this really should
work.

The panic occurs when you have `nodeModulesDir: manual` (or a
package.json present), and you have an npm package with a tag in your
deno.json (see the spec test that illustrates this).

This code path only actually executes when trying to choose an
appropriate package version from `node_modules/.deno`, so we should be
able to fix it by storing some extra data at install time.

The fix proposed here is to repurpose the `.initialized` file that we
store in `node_modules` to store the tags associated with a package.
Basically, if you have a version requirement with a tag (e.g.
`npm:chalk@latest`), when we set up the node_modules folder for that
package, we store the tag (`latest`) in `.initialized`. Then, when doing
BYONM resolution, if we have a version requirement with a tag, we read
that file and check if the tag is present.

The downside is that we do more work when setting up `node_modules`. We
_could_ do this only when BYONM is enabled, but that would have the
downside of needing to re-run `deno install` when you switch from auto
-> manual, though maybe that's not a big deal.
2024-10-02 17:16:46 -07:00
Nathan Whitaker
cb74975ab2
fix(install): compare versions directly to decide whether to create a child node_modules dir for a workspace member (#26001)
Fixes #25861.

Previously we were attempting to match the version requirement against
the version already present in `node_modules` root, and if they didn't
match we would create a node_modules dir in the workspace member's
directory with the dependency.

Aside from the fact that this caused the panic, on second thought it
just doesn't make sense in general. We shouldn't be semver matching, as
resolution has already occurred and decided what package versions are
required. Instead, we can just compare the versions directly.
2024-10-02 15:11:43 -07:00
David Sherret
69ab720025
refactor: move ByonmNpmResolver to deno_resolver (#25937)
Some more slow progress on moving all the resolution code into
deno_resolver.
2024-09-30 13:33:32 +00:00
David Sherret
1bb47805d6
refactor: move NpmCacheDir to deno_cache_dir (#25916)
Part of the ongoing work to move more of Deno's resolution out of the
CLI crate (for use in Wasm and other things)

Includes:

* https://github.com/denoland/deno_cache_dir/pull/60
2024-09-28 08:50:16 -04:00
Nathan Whitaker
36ebc03f17
fix(cli): Warn on not-run lifecycle scripts with global cache (#25786)
Refactors the lifecycle scripts code to extract out the common
functionality and then uses that to provide a warning in the global
resolver.

While ideally we would still support them with the global cache, for now
a warning is at least better than the status quo (where people are
unaware why their packages aren't working).
2024-09-24 19:23:57 +00:00
Bartek Iwańczuk
5b14c71daf
feat: improve warnings for deprecations and lifecycle script for npm packages (#25694)
This commit improves warning messages for deprecated npm packages
and packages that rely on lifecycle script.
2024-09-18 19:04:25 +00:00
David Sherret
72f025c743
fix: remove recently added deno.json node_modules aliasing (#25542)
This was initially added in #25399 in order to make transitioning over
from package.json to deno.json more easy, but it causes some problems
that are shown in the issue and it also means that the output of `deno
install` would have different resolution than `npm install`. Overall, I
think it's too much complexity to be smarter about this and it's
probably best to not do it. If someone needs an aliased folder then they
should keep using a package.json

Closes #25538
2024-09-09 20:19:29 +00:00
Nathan Whitaker
292344af42
fix(install): Make sure target node_modules exists when symlinking (#25494)
Fixes https://github.com/denoland/deno/issues/25493
2024-09-06 19:08:56 +00:00
David Sherret
c6d1b0a1cc
fix(byonm): resolve npm deps of jsr deps (#25399)
This allows using npm deps of jsr deps without having to add them to the
root package.json.

Works by taking the package requirement and scanning the
`node_modules/.deno` directory for the best matching package, so it
relies on deno's node_modules structure.

Additionally to make the transition from package.json to deno.json
easier, Deno now:

1. Installs npm deps in a deno.json at the same time as installing npm
deps from a package.json.
2. Uses the alias in the import map for `node_modules/<alias>` for
better package.json compatiblity.
2024-09-04 14:00:44 +00:00
David Sherret
bf7571a6f9
fix: make some warnings more standard (#25324) 2024-09-03 10:45:01 +02:00
David Sherret
f891e73bbf
refactor: remove DENO_FUTURE (#25314) 2024-08-30 21:58:24 +00:00
Nathan Whitaker
f606402677
fix(install): Use relative symlinks in deno install (#25164)
Fixes https://github.com/denoland/deno/issues/25161
2024-08-22 21:55:17 +00:00
HasanAlrimawi
0704454755
feat: Print deprecation message for npm packages (#24992)
This commit adds ability to print deprecation notices
for npm packages that have been marked as deprecated.

Closes #24013
2024-08-20 19:53:53 +02:00
Nathan Whitaker
854c7ba198
fix(install): Properly handle dist tags when setting up node_modules (#24968)
Fixes https://github.com/denoland/deno/issues/24966.
Fixes https://github.com/denoland/deno/issues/24932.
2024-08-09 13:35:54 +00:00
Satya Rohith
8c2f1f5a55
chore: upgrade to rust 1.80 (#24778) 2024-07-29 12:58:04 -04:00
David Sherret
3bf147fe28
refactor: decouple node resolution from deno_core (#24724) 2024-07-25 19:08:14 -04:00
David Sherret
52ababc4bf
fix(node): better detection for when to surface node resolution errors (#24653) 2024-07-24 00:22:24 +00:00
Nathan Whitaker
a4c76add56
fix(cli): Respect implied BYONM from DENO_FUTURE in deno task (#24652)
Regression from
04f9db5b22

Originally I thought to fix the issue in the PR we needed to explicitly
pass through the `node-modules-dir` flag, but after applying the correct
fix that david pointed out (setting `NPM_PROCESS_STATE`) that wasn't
necessary (or correct).

We had a test for deno task with BYONM, but it only tested with
`"unstable": ["byonm"]` in deno.json, so it didn't catch this.
2024-07-19 18:59:04 +00:00
Nathan Whitaker
c9da27e147
fix(cli): Create child node_modules for conflicting dependency versions, respect aliases in package.json (#24609)
Fixes #24419.
2024-07-16 20:30:28 +00:00
Nathan Whitaker
04f9db5b22
fix(node): Fix --allow-scripts with no deno.json (#24533)
We would resolve the wrong package.json, resulting in an inability to
run CJS (or other node-mode) scripts
2024-07-15 12:11:09 -07:00
David Sherret
29186d7e59
fix(workspace): do not resolve to self for npm pkg depending on matching req (#24591)
Closes #24584
2024-07-15 15:08:51 -04:00
Nathan Whitaker
3d0e1b65b1
fix(node): Ignore broken default install scripts (#24534)
NPM inserts a default install script when a package has a `binding.gyp`
file.

It's possible, however, for the package to exclude the `binding.gyp`
file when they publish, and in this case the install script will never
succeed for a user of the package.

This happens with `fsevents`, for instance. They don't include the
`binding.gyp` file in their published tarball, but the default install
script appears in the manifest served by `npm`.

This causes us to warn that `fsevents` has an install script, but when
you try to run it it fails due to `binding.gyp` not existing.
2024-07-11 18:39:45 +00:00
David Sherret
f950f59983
fix(npm): only warn about lifecycle scripts not being run when setting up directory (#24530)
Closes #24518
2024-07-11 16:41:42 +00:00
Nathan Whitaker
69afa8718f
chore: tweak warning message for un-run install scripts (#24508)
Previously when we printed out the packages that skipped install
scripts, we didn't prefix them with `npm:`. When you pass
`--allow-scripts` though, we require `npm:`, which means you can't just
copy paste the package name from the warning message.
2024-07-10 18:03:41 +00:00
Nathan Whitaker
ce7dc2be92
feat(node): Support executing npm package lifecycle scripts (preinstall/install/postinstall) (#24487)
Adds support for running npm package lifecycle scripts, opted into via a
new `--allow-scripts` flag.

With this PR, when running `deno cache` (or `DENO_FUTURE=1 deno
install`) you can specify the `--allow-scripts=pkg1,pkg2` flag to run
lifecycle scripts attached to the given packages.

Note at the moment this only works when `nodeModulesDir` is true (using
the local resolver).

When a package with un-run lifecycle scripts is encountered, we emit a
warning suggesting things may not work and to try running lifecycle
scripts. Additionally, if a package script implicitly requires
`node-gyp` and it's not found on the system, we emit a warning.

Extra things in this PR:
- Extracted out bits of `task.rs` into a separate module for reuse
- Added a couple fields to `process.config` in order to support
`node-gyp` (it relies on a few variables being there)
- Drive by fix to downloading new npm packages to test registry

---

TODO:
- [x] validation for allow-scripts args (make sure it looks like an npm
package)
- [x] make allow-scripts matching smarter
- [ ] figure out what issues this closes

---
Review notes:
- This adds a bunch of deps to our test registry due to using
`node-gyp`, so it's pretty noisy
2024-07-10 03:06:08 +00:00
Zebreus
3c91d597ce
fix: make .setup-cache.bin in node_modules more reproducible (#24480) 2024-07-09 18:04:21 +00:00
David Sherret
839caf6faf
refactor: use concrete error types for node resolution (#24470)
This will help clean up some of the code in the CLI because we'll be
able to tell how the resolution failed (not part of this PR).
2024-07-09 12:15:03 -04:00
David Sherret
147411e64b
feat: npm workspace and better Deno workspace support (#24334)
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/66

Closes #24340
Closes #24159
Closes #24161
Closes #22020
Closes #18546
Closes #16106
Closes #24160
2024-07-04 00:54:33 +00:00
David Sherret
31154ff958
fix(check): attempt to resolve types from pkg before @types pkg (#24152)
I've been meaning to fix this for ages, but I finally ran into it here:


https://github.com/dsherret/ts-ast-viewer/actions/runs/9432038675/job/25981325408

We need to resolve the `@types` package as a fallback instead of eagerly
resolving it.
2024-06-08 20:05:28 -04:00
David Sherret
ed20102713
fix: make writing to the deps cache more reliable (#24135)
I was able to reproduce this locally.

```
[error] Failed to execute snippet: 
import { validate } from "@std/uuid";
import { assert, assertFalse } from "@std/assert";

assert(validate("6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b"));
assertFalse(validate("not a UUID"));
Download https://jsr.io/@std/uuid/meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1_meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/common.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/constants.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v1.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v3.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v4.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v5.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/_common.ts
error: Access is denied. (os error 5) (for 'V:\.cache\deno\deps\https\jsr.io\2ae5bb614c7526d0876be0b76da1372fd51304ae27d6202ee94df720b3523d08')
 at file:///V:/deno_std/uuid/common.ts:43
[error] Failed to execute snippet:
import { v5, NAMESPACE_DNS, NIL_UUID } from "@std/uuid";
import { assert, assertFalse } from "@std/assert";

const data = new TextEncoder().encode("deno.land");
const uuid = await v5.generate(NAMESPACE_DNS, data);

assert(v5.validate(uuid));
assertFalse(v5.validate(NIL_UUID));
Download https://jsr.io/@std/uuid/meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1_meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/common.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/constants.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v1.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v3.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v4.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v5.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/_common.ts
error: Access is denied. (os error 5) (for 'V:\.cache\deno\deps\https\jsr.io\63dd818c5fc1ac39c04df9b42bd9dd4bbc07f7d1b174e405d003731125778da1')
    at https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts:30:15
 at file:///V:/deno_std/uuid/mod.ts:4
[error] Failed to execute snippet:
import { isNil } from "@std/uuid";
import { assert, assertFalse } from "@std/assert";

assert(isNil("00000000-0000-0000-0000-000000000000"));
assertFalse(isNil(crypto.randomUUID()));
Download https://jsr.io/@std/uuid/meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1_meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/common.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/constants.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v1.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v3.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v4.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v5.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/_common.ts
error: Access is denied. (os error 5) (for 'V:\.cache\deno\deps\https\jsr.io\fd3a12fc091d16ee29f10fa7a05eeeb8bd6c3cc014642e72478c757f00e7261e')
    at https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts:34:40
 at file:///V:/deno_std/uuid/common.ts:23
[error] Failed to execute snippet:
import { version } from "@std/uuid";
import { assertEquals } from "@std/assert/assert-equals";

assertEquals(version("d9428888-122b-11e1-b85c-61cd3cbb3210"), 1);
assertEquals(version("6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b"), 4);
Download https://jsr.io/@std/uuid/meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1_meta.json
Download https://jsr.io/@std/uuid/1.0.0-rc.1/mod.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/common.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/constants.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v1.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v3.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v4.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/v5.ts
Download https://jsr.io/@std/uuid/1.0.0-rc.1/_common.ts
error: Access is denied. (os error 5) (for 'V:\.cache\deno\deps\https\jsr.io\2ae5bb614c7526d0876be0b76da1372fd51304ae27d6202ee94df720b3523d08')
 at file:///V:/deno_std/uuid/common.ts:66
4 errors found
```

It occurs when many Deno processes are writing to the deps cache at the
same time. Fix is to use `atomic_write_with_retries` which is much more
reliable (and the function that helped make the ecosystem tests more
reliable too). After this change I no longer have this issue.

Closes https://github.com/denoland/deno/issues/24073
2024-06-07 13:06:17 -04:00
David Sherret
386d5c8310
refactor: remove PermissionsContainer in deno_runtime (#24119)
Also removes permissions being passed in for node resolution. It was
completely useless because we only checked it for reading package.json
files, but Deno reading package.json files for resolution is perfectly
fine.

My guess is this is also a perf improvement because Deno is doing less
work.
2024-06-06 23:37:53 -04:00
David Sherret
7a17eba5a7
refactor: NpmRegistryApi - #[async_trait(?Send)] (#24126) 2024-06-06 22:37:41 +00:00
David Sherret
3341c50b6a
refactor: don't share reqwest::HttpClient across tokio runtimes (#24092)
This also fixes several issues where we weren't properly creating http
clients with the user's settings.
2024-06-03 21:17:08 +00:00
David Sherret
b1f776adef
refactor: extract structs for downloading tarballs and npm registry packuments (#24067) 2024-06-03 01:39:13 +00:00
Nathan Whitaker
a379009bfd
fix(cli): Prefer npm bin entries provided by packages closer to the root (#24024)
Fixes #24012.

In the case of multiple packages providing a binary with a same name, we
were basically leaving the results undefined (since we set up things in
parallel, and whichever got set up first won). In addition, we were
warning about these cases, even though it's a situation that's expected
to occur.

Instead, in the case of a collision in the binary names, we prefer the
binary provided by the package with the least depth in the dependency
tree.

While I was at it, I also took moved more code to `bin_entries.rs` since
it was starting to get a bit cluttered.
2024-05-29 17:45:22 -07:00
Nathan Whitaker
2024c974b6
perf(cli): Improve concurrency when setting up node_modules and loading cached npm package info (#24018)
The same issue in two different places - doing blocking FS work in an
async task, limiting the amount of work that happens concurrently.

- When setting up node_modules, where we try to set up entries
concurrently but were blocking other tasks from actually running.
- When loading package info from the npm registry file cache, loading
and deserializing is expensive and prevents concurrency. This was
especially noticeable when loading an npm resolution snapshot from a
lockfile (`snapshot_from_lockfile` in `deno_npm`).

Installing deps in `deno-docs`:

```
❯ hyperfine -i -p 'rm -rf node_modules/' '../d7/deno-main i' '../d7/target/release/deno i'
Benchmark 1: ../d7/deno-main i
  Time (mean ± σ):      2.193 s ±  0.027 s    [User: 0.589 s, System: 1.033 s]
  Range (min … max):    2.151 s …  2.242 s    10 runs

Benchmark 2: ../d7/target/release/deno i
  Time (mean ± σ):      1.597 s ±  0.021 s    [User: 0.977 s, System: 1.337 s]
  Range (min … max):    1.550 s …  1.627 s    10 runs

Summary
  ../d7/target/release/deno i ran
    1.37 ± 0.02 times faster than ../d7/deno-main i
```

Caching `npm:@11ty/eleventy`:
```
❯ hyperfine -i -p 'rm -rf node_modules/' --warmup 5 '../../d7/deno-main cache npm:@11ty/eleventy' '../../d7/target/release/deno cache npm:@11ty/eleventy'
Benchmark 1: ../../d7/deno-main cache npm:@11ty/eleventy
  Time (mean ± σ):     129.9 ms ±   2.2 ms    [User: 27.5 ms, System: 101.3 ms]
  Range (min … max):   127.5 ms … 135.8 ms    10 runs

Benchmark 2: ../../d7/target/release/deno cache npm:@11ty/eleventy
  Time (mean ± σ):     100.6 ms ±   1.3 ms    [User: 38.8 ms, System: 233.8 ms]
  Range (min … max):    99.3 ms … 103.2 ms    10 runs

Summary
  ../../d7/target/release/deno cache npm:@11ty/eleventy ran
    1.29 ± 0.03 times faster than ../../d7/deno-main cache npm:@11ty/eleventy
```

---------

Co-authored-by: David Sherret <dsherret@gmail.com>
2024-05-28 21:17:36 +00:00
Nathan Whitaker
3e8f29ae41
perf(cli): Optimize setting up node_modules on macOS (#23980)
Hard linking (`linkat`) is ridiculously slow on mac. `copyfile` is
better, but what's even faster is `clonefile`. It doesn't have the space
savings that comes with hardlinking, but the performance difference is
worth it imo.

```
❯ hyperfine -i -p 'rm -rf node_modules/' '../../d7/target/release/deno cache npm:@11ty/eleventy' 'deno cache npm:@11ty/eleventy'
Benchmark 1: ../../d7/target/release/deno cache npm:@11ty/eleventy
  Time (mean ± σ):     115.4 ms ±   1.2 ms    [User: 27.2 ms, System: 87.3 ms]
  Range (min … max):   113.7 ms … 117.5 ms    10 runs

Benchmark 2: deno cache npm:@11ty/eleventy
  Time (mean ± σ):     619.3 ms ±   6.4 ms    [User: 34.3 ms, System: 575.6 ms]
  Range (min … max):   612.2 ms … 633.3 ms    10 runs

Summary
  ../../d7/target/release/deno cache npm:@11ty/eleventy ran
    5.37 ± 0.08 times faster than deno cache npm:@11ty/eleventy
```
2024-05-28 11:59:17 -07:00
Bartek Iwańczuk
92a8d09e49
fix(npm): set up node_modules/.bin/ entries for package that provide bin entrypoints (#23496)
Closes https://github.com/denoland/deno/issues/23036

---------

Co-authored-by: Nathan Whitaker <nathan@deno.com>
2024-05-23 23:43:38 +00:00
Bartek Iwańczuk
959739f609
FUTURE: initial support for .npmrc file (#23560)
This commit adds initial support for ".npmrc" files.

Currently we only discover ".npmrc" files next to "package.json" files
and discovering these files in user home dir is left for a follow up.

This pass supports "_authToken" and "_auth" configuration
for providing authentication.

LSP support has been left for a follow up PR.

Towards https://github.com/denoland/deno/issues/16105
2024-05-23 23:26:23 +02:00
David Sherret
bc4aa5f901
fix(npm): do not panic hitting root dir while resolving npm package (#23556)
Closes https://github.com/denoland/deno/issues/23029
2024-04-25 14:13:55 +00:00
Divy Srivastava
e0c9102b49
perf: hard link npm cache (#22773) 2024-03-07 13:10:19 -05:00
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
David Sherret
9bdc9e4ecb
fix(npm): do not create symlink for non-system optional dep in node_modules directory (#21478)
Closes https://github.com/denoland/deno/issues/21476
2023-12-06 14:24:00 -05:00
David Sherret
9ac405d587
feat(compile): support "bring your own node_modules" in deno compile (#21377)
Not tested thoroughly. This is a good start.

Closes #21350
2023-11-29 09:32:23 -05:00
David Sherret
be97170a19
feat(unstable): ability to npm install then deno run main.ts (#20967)
This PR adds a new unstable "bring your own node_modules" (BYONM)
functionality currently behind a `--unstable-byonm` flag (`"unstable":
["byonm"]` in a deno.json).

This enables users to run a separate install command (ex. `npm install`,
`pnpm install`) then run `deno run main.ts` and Deno will respect the
layout of the node_modules directory as setup by the separate install
command. It also works with npm/yarn/pnpm workspaces.

For this PR, the behaviour is opted into by specifying
`--unstable-byonm`/`"unstable": ["byonm"]`, but in the future we may
make this the default behaviour as outlined in
https://github.com/denoland/deno/issues/18967#issuecomment-1761248941

This is an extremely rough initial implementation. Errors are
terrible in this and the LSP requires frequent restarts. Improvements
will be done in follow up PRs.
2023-10-25 14:39:00 -04:00