Closes https://github.com/denoland/deno/issues/29897.
Closes https://github.com/denoland/deno/issues/14066.
Closes https://github.com/denoland/deno/issues/19955.
With this PR we'll attempt to resolve bare specifiers passed to `run` or
`serve` with the workspace resolver. This means you can run specifiers
that are defined in your import map/package.json.
If the specifier looks like a path (starts with `.`, or is an absolute
path) then we won't try to resolve it via the import map.
This does have the potential to break someone, in the case that you have
something like
```
{
"imports": { "foo.ts": "./bar.ts" }
}
```
and you have a file named `foo.ts`, previously `deno run foo.ts` would
run `./foo.ts`, now we would run `./bar.ts`. I can't see a way around
that without doing an extra stat to see if the file exists, or deferring
this to module load time (which seems complex). I don't think many
people would hit that, and if someone does there's a simple fix – just
add `./` to the front.
From my benchmarking, this change has no effect on startup time
Fixes https://github.com/denoland/deno/issues/29707.
Not particularly happy with this one, but the only other idea I had was
to just ignore errors about non-existent exports when we build the graph
for a top level install. That might end up being the best solution.
For background, when you do a top level install that includes a jsr
dependency, we fetch the exports for the jsr package and then use those
exports as roots in the module graph (which triggers caching those
files).
To find those exports correctly, we need to know what version will end
up being cached, otherwise we may end up trying to reference exports
that don't exist on the actual package.
Previously, we could just look up the version in the lockfile and that
worked, but it turns out that was depending on the behavior that was
reverted in https://github.com/denoland/deno/pull/29642.
Fixes#27038.
Previously, for NPM packages the latest version was the version with the
"latest" tag. For JSR packages, the latest version was the greatest
version that matched a `*` version requirement. Unfortunately, that
doesn't work well with pre-release versions.
This PR changes it so that the latest version is always > the currently
requested version.
For NPM: if "latest" tag > current then "latest" tag; otherwise the
greatest version that is >= current
For JSR: greatest version >= current
This is the most reasonable behavior I could come up with. For example,
```
versions:
2.0.0-beta.2
2.0.0-beta.1
1.0.0 => "latest" tag
with a version req `^2.0.0-beta.1`
previously:
"Update" column => 2.0.0-beta.2
"Latest" column => 1.0.0
now:
"Update" column => 2.0.0-beta.2
"Latest" column => 2.0.0-beta.2
```
Closes#20487
Currently spelled
```
deno outdated
```
and
```
deno outdated --update
```
Works across package.json and deno.json, and in workspaces.
There's a bit of duplicated code, I'll refactor to reduce this in follow
ups
## Currently supported:
### Printing outdated deps (current output below which basically mimics
pnpm, but requesting feedback / suggestions)
```
deno outdated
```
### Updating deps
semver compatible:
```
deno outdated --update
```
latest:
```
deno outdated --latest
```
current output is basic, again would love suggestions
#### Filters
```
deno outdated --update "@std/*"
deno outdated --update --latest "@std/* "!@std/fmt"
```
#### Update to specific versions
```
deno outdated --update @std/fmt@1.0.2 @std/cli@^1.0.3
```
### Include all workspace members
```
deno outdated --recursive
deno outdated --update --recursive
```
## Future work
- interactive update
- update deps in js/ts files
- better support for transitive deps
Known issues (to be fixed in follow ups):
- If no top level dependencies have changed, we won't update transitive
deps (even if they could be updated)
- Can't filter transitive deps, or update them to specific versions
## TODO (in this PR):
- ~~spec tests for filters~~
- ~~spec test for mixed workspace (have tested manually)~~
- tweak output
- suggestion when you try `deno update`
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes https://github.com/denoland/deno/issues/26509.
Ended up being a `deno_graph` bug causing the error to surface. This PR
updates `deno_graph` to pick up the fix and reverts the temporary
workaround that skipped JSON exports.
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.
