1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-30 02:59:11 -05:00
Commit graph

7 commits

Author SHA1 Message Date
Marvin Hagemeister
4b99cde504
fix(npm): ensure scoped package name is encoded in URLs (#26390)
Fixes https://github.com/denoland/deno/issues/26385
2024-10-18 20:38:57 +02:00
Nathan Whitaker
13c53d9727
fix(installl): make bin entries executable even if not put in node_modules/.bin (#25873)
Fixes https://github.com/denoland/deno/issues/25862.

npm only makes bin entries executable if they get linked into `.bin`, as
we did before this PR. So this PR actually deviates from npm, because
it's the only reasonable way to fix this that I can think of.

---

The reason this was broken in moment is the following:

Moment has dependencies on two typescript versions: 1.8 and 3.1

If you have two packages with conflicting bin entries (i.e. two
typescript versions which both have a bin entry `tsc`), in npm it is
non-deterministic and undefined which one will end up in `.bin`.

npm, due to implementation differences, chooses to put typescript 1.8
into the `.bin` directory, and so `node_modules/typescript/bin/tsc` ends
up getting marked executable. We, however, choose typescript 3.2, and so
we end up making `node_modules/typescript3/bin/tsc` executable.

As part of its tests, moment executes `node_modules/typescript/bin/tsc`.
Because we didn't make it executable, this fails.

Since the conflict resolution is undefined in npm, instead of trying to
match it, I think it makes more sense to just make bin entries
executable even if they aren't chosen in the case of a conflict.
2024-09-26 09:36:25 -07:00
Bartek Iwańczuk
4e19474129
chore: remove DENO_FUTURE=1 from spec tests (#25329)
Towards https://github.com/denoland/deno/issues/25241
2024-08-31 21:25:32 +00:00
David Sherret
f891e73bbf
refactor: remove DENO_FUTURE (#25314) 2024-08-30 21:58:24 +00:00
Nathan Whitaker
86d5b919d8
feat(config): Node modules option for 2.0 (#25299) 2024-08-29 15:57:43 -07:00
Nathan Whitaker
795ed23b35
fix(future): Emit deno install warning less often, suggest deno install in error message (#24706)
Two small changes:

- In our BYONM errors, suggest running `deno install` instead of `npm
install` if `DENO_FUTURE` is set
- Only emit warning about `deno install` changes if you do `deno install
<foo>` with deno_future unset
2024-07-24 23:37: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