1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-27 01:29:14 -05:00
Commit graph

9 commits

Author SHA1 Message Date
denobot
22a79ea420
2.0.2 (#26374)
Bumped versions for 2.0.2

Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-10-18 01:28:36 +02:00
denobot
99c2aa5730
2.0.1 (#26335)
Bumped versions for 2.0.1

Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-10-17 00:42:35 +02:00
denobot
a62c7e036a
2.0.0 (#26063)
Bumped versions for 2.0.0

Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-10-08 07:37:28 -07: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
David Sherret
cac28b5262
feat(byonm): support deno run npm:<package> when package is not in package.json (#25981)
Closes https://github.com/denoland/deno/issues/25905
2024-10-02 21:17:39 +01:00
denobot
55c2a88099
chore: release deno_* crates (#25987)
Testing once again if the crates are being properly released.

---------

Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-10-02 14:27:34 +00:00
denobot
2d3e0284d9
chore: release deno_* crates (#25976)
Test run before Deno 2.0 release to make sure that the publishing
process passes correctly.

---------

Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-10-02 14:44:04 +02: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
5faf769ac6
refactor: extract out sloppy imports resolution from CLI crate (#25920)
This is slow progress towards creating a `deno_resolver`  crate.

Waiting on:

* https://github.com/denoland/deno/pull/25918
* https://github.com/denoland/deno/pull/25916
2024-09-28 19:17:48 -04:00