Fixes https://github.com/denoland/deno/issues/30510
Basically we save the error for later, return `None` to esbuild. Later
when we process esbuild errors, if esbuild failed to resolve the same
package then we use our error message instead of esbuild's
Also this changes how we print out the esbuild errors to include the
notes, which can often be useful
Fixes a case reported in discord. At runtime node (and us) would fail on
this, but all major bundlers permit this. So as a fix, just allow it
during bundling only.
Closes#29650.
Currently passing `--platform=browser` does two things:
- makes us prefer the `"browser"` key in package json over module and
main
- makes us prefer the `"browser"` export condition
but we may add more things in the future
This change specifically allows op_require_stat to stat node_module
directories without having to go through the permission system.
Closes https://github.com/denoland/deno/issues/20484
This was actually fixed via the deno_npm and lockfile updates, but it
would be good to have an explicit entry for this in the release notes so
labeling this as a "fix"
Closes https://github.com/denoland/deno/issues/27758
Fixes#28891
We were checking if the node_modules entry for the package was present,
but then reading from the global cache.
Instead, read from the package.json in node_modules. As a fallback(which
in theory should only really happen if the node_modules dir is somehow
messed up), take the more expensive (but likely to work) path of reading
from the registry.json.
Apparently things like the `bin` field can appear in the version info
from the registry, but not the package's `package.json`. I'm still not
sure how you actually achieve this, but it's the case for
`esbuild-wasm`. This fixes the following panic:
```
❯ deno i --node-modules-dir npm:esbuild-wasm
Add npm:esbuild-wasm@0.25.2
Initialize ⣯ [00:00]
- esbuild-wasm@0.25.2
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: macos aarch64
Version: 2.2.8+58c6c0b
Args: ["deno", "i", "--node-modules-dir", "npm:esbuild-wasm"]
View stack trace at:
https://panic.deno.com/v2.2.8+58c6c0bc9c1b4ee08645be936ff9268f17028f0f/aarch64-apple-darwin/g4h6Jo393pB4k4kqBo-3kqBg6klqBogtyLg13yLw_t0Lw549Hgj8-Hgw__H428-F4yv_HgjkpKww7gIon4gIw54rKwi5MorzMw5y7G42g7Iw---I40s-I4vu4Jw2rEw8z7Dwnr6J4tp7Bo_vvK
thread 'main' panicked at cli/npm/installer/common/bin_entries.rs:108:30:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This improves peer dependency resolution to be more relaxed and resolve
non-version matching ancestors similar to pnpm rather than introducing
duplicate dependencies. Deno will warn when this occurs. In the future,
we should look into introducing an option to have Deno error in this
scenario.
Fixes https://github.com/denoland/deno/issues/27569.
Fixes https://github.com/denoland/deno/issues/27215.
This PR makes it so type resolution falls back to looking for definitely
typed packages (`@types/foo`) if a given NPM package does not contain
type declarations.
One complication is choosing _which_ version of the `@types/*` package
to use, if the project depends on multiple versions. The heuristic here
is to try to match the major and minor versions, falling back to the
latest version. So if you have
```
@types/foo: 0.1.0, 0.2.0, 3.1.0, 3.1.2, 4.0.0
foo: 3.1.0
```
we would choose `@types/foo@3.1.2` when resolving types for `foo`.
---
Note that this only uses `@types/` packages if you _already_ depend on
them. So a follow up to this PR could be to add a diagnostic and
quickfix to install `@types/foo` if we don't find types for `foo`.
This PR resolves 2 issues of Socket class of node compat (both are
related to playwright)
Currently `browser.launch()` of playwright is not working.
`browser.launch` opens PipeTransport (which is based on Pipe/IPC socket)
with the browser process. But that pipe doesn't start reading the data
because of the workaround #27662 (which pauses the socket at the
beginning if it's from playwright-core). This PR fixes this issue by
checking whether the given handle is `ipc` handle or not.
Another issue is that sock-init-workaround for TLS connection stopped
working at #27707 because of the changes of TLS socket initialization
steps. This change fixes the issue by correctly returning the function
in workaround path.
The added case `specs::npm::playwright_compat` checks both fixes with
actual playwright and playwright-core packages.
`browser.launch` issues
closes#16899closes#27623
`https.request` issue
closes#27658
This commit changes "Deno.cwd()" (as well as "process.cwd()") to no
longer require full "--allow-read" permission. This change was meant to be done
in Deno 2.0.0, but somehow it slipped. Requiring full read permission
just to read the CWD is a mistake, because CWD can already be obtained
with no permission by throwing an error in JS and inspecting its stack.
Fixes https://github.com/denoland/deno/issues/27110
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes#26224.
Fixes#27042.
There were three bugs here:
- we were only resolving `/// <reference types` directives starting with
`npm:`, which meant we failed to resolve bare specifiers (this broke the
`/// <reference types="vite/client">` directive in most of the vite
templates)
- the `$node_modules` workaround caused us to fail to read files for
tsc. For instance tsc would construct new paths based on specifiers
containing `$node_modules`, and since we hadn't created those we weren't
mapping them back to the original (this broke some type resolution
within `vite/client`)
- our separation of `ImportMeta` across node and deno globals in tsc
meant that npm packages couldn't augment `ImportMeta` (this broke
`vite/client`'s augmentation to add `import.meta.env` and others)
After this, the only remaining issue in the vanilla vite template is our
error on `/vite.svg` (which is an ambient module), and I'll look into
that next.
Fixes https://github.com/denoland/deno/issues/27062
In the LSP we were passing `npm` specifiers to TSC as roots, but TSC
needs fully resolved specifiers (like the actual file path).
In `deno check` we were often excluding the specifiers entirely from the
roots.
In both cases, we need to resolve the specifiers fully and then pass
them to tsc
See the comment
https://github.com/denoland/deno/pull/25470#issuecomment-2435077722 for
the reason why we do this workaround to make `make-fetch-happen` work in
Deno
This PR applies the same workaround to `npm-check-updates` package.
`npm-check-updates` internally uses
[`npm-registry-fetch`](https://www.npmjs.com/package/npm-registry-fetch)
which uses
[`make-fetch-happen`](https://www.npmjs.com/package/make-fetch-happen)
(the problematic package) for making http request to npm registry.
The detection of `make-fetch-happen` doesn't work for
`npm-check-updates` because we use call stack at `net.Socket`
constructor to check if it's called from `make-fetch-happen`, but
`npm-check-updates` bundles its dependency and the check doesn't work.
This PR adds the check of `npm-check-updates` string in call stack in
net.Socket constructor to trigger the workaroud.
closes#27629
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>
The issue was this package had an import like: `".//index.js"` and we
resolved that as specified, but node normalizes it to `"./index.js"` so
we have to copy node.
This PR removes the public Deno.tracing.Span API.
We are not confident we can ship an API that is
better than the `@opentelemetry/api` API, because
V8 CPED does not support us using `using` to
manage span context. If this changes, we can
revisit this decision. For now, users wanting
custom spans can instrument their code using
the `@opentelemetry/api` API and `@deno/otel`.
This PR also speeds up the OTEL trace generation
by a 30% by using Uint8Array instead of
strings for the trace ID and span ID.
This will respect `"type": "commonjs"` in a package.json to determine if
`.js`/`.jsx`/`.ts`/.tsx` files are CJS or ESM. If the file is found to
be ESM it will be loaded as ESM though.
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).
Fixes https://github.com/denoland/deno/issues/24749
Runs a server that just returns the header tarball and checksum, and
sets the `NODEJS_ORG_MIRROR` env var so that `node-gyp` uses it instead
of `nodejs.org`
* 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>
Fixes#25342.
Still not sure on the exact user agent to set (should it include
`node`?).
After this PR, here's the state of running some `create-*` packages
(just ones I could think of off the top of my head):
| package | prints/runs/suggests deno install | notes |
| ---------------- | ------------- | ------ |
| `create-next-app` | ❌ | falls back to npm, needs a PR
([code](c32e280209/packages/create-next-app/helpers/get-pkg-manager.ts (L3)))
| `sv create` | ❌ | uses `package-manager-detector`, needs a PR
([code](https://github.com/antfu-collective/package-manager-detector/tree/main))
| `create-qwik` | ✅ | runs `deno install` but suggests `deno start`
which doesn't work (should be `deno task start` or `deno run start`)
| `create-astro` | ✅ | runs `deno install` but suggests `npm run dev`
later in output, probably needs a PR
| `nuxi init` | ❌ | deno not an option in dialog, needs a PR
([code](f04e2e8944/src/commands/init.ts (L96-L102)))
| `create-react-app` | ❌ | uses npm
| `ng new` (`@angular/cli`) | ❌ | uses npm
| `create-vite` | ✅ | suggests working deno commands 🎉
| `create-solid` | ❌ | suggests npm commands, needs PR
It's possible that fixing `package-manager-detector` or other packages
might make some of these just work, but haven't looked too carefully at
each
Fixes https://github.com/denoland/deno/issues/26505
I'm not exactly sure how this case comes about (I tried to write tests
for it but couldn't manage to reproduce it), but what happens is the
parent filename ends up null, and we bail out of resolving the specifier
in package exports.
I've checked, and in node the parent filename is also null (so that's
not a bug on our part), but node continues to resolve even in that case.
So this PR should match node's behavior more closely than we currently
do.
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.
