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 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).
* 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
Spend some time stepping through the npm client code and noticed that
the bearer token was different from ours. They do some double encoding
and @dsherret helped me in matching the encoding behavior.
Fixes https://github.com/denoland/deno/issues/26033
Currently we only warn once. With this PR, we continue to warn about
not-run scripts on explicit `deno install` (or cache). For `run` (or
other subcommands) we only warn the once, as we do currently.
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.
This replaces `--allow-net` for import permissions and makes the
security sandbox stricter by also checking permissions for statically
analyzable imports.
By default, this has a value of
`--allow-import=deno.land:443,jsr.io:443,esm.sh:443,raw.githubusercontent.com:443,gist.githubusercontent.com:443`,
but that can be overridden by providing a different set of hosts.
Additionally, when no value is provided, import permissions are inferred
from the CLI arguments so the following works because
`fresh.deno.dev:443` will be added to the list of allowed imports:
```ts
deno run -A -r https://fresh.deno.dev
```
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
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).
`--allow-run` even with an allow list has essentially been
`--allow-all`... this locks it down more.
1. Resolves allow list for `--allow-run=` on startup to an absolute
path, then uses these paths when evaluating if a command can execute.
Also, adds these paths to `--deny-write`
1. Resolves the environment (cwd and env vars) before evaluating
permissions and before executing a command. Then uses this environment
to evaluate the permissions and then evaluate the command.
`deno bundle` now produces:
```
error: ⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
```
`deno bundle --help` now produces:
```
⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
Usage: deno bundle [OPTIONS]
Options:
-q, --quiet Suppress diagnostic output
--unstable Enable all unstable features and APIs. Instead of using this flag, consider enabling individual unstable features
To view the list of individual unstable feature flags, run this command again with --help=unstable
```
This commit effectively turns Deno into Deno 2.0.
This is done by forcing `DENO_FUTURE=1` env var, that was available in
the past few months to try Deno 2 changes.
This commit contains several breaking changes scheduled for Deno 2:
- all deprecated JavaScript APIs are not available any more, mostly
`Deno.*` APIs
- `window` global is removed
- FFI, WebGPU and FS APIs are now stable and don't require
`--unstable-*` flags
- import assertions are no longer supported
- "bring your own node modules" is enabled by default
This is the first commit in a series that are scheduled before the Deno
2 release.
Follow up work is tracked in
https://github.com/denoland/deno/issues/25241.
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
Co-authored-by: Nathan Whitaker <nathan@deno.com>
Stores normalized version constraints in the lockfile, which will
improve reproducibility and will fix a bug with duplicate specifiers
ending up in the lockfile. Also, gets rid of some duplicate data in the
specifiers area of the lockfile.
This commit enables the `log` feature for the `tracing` crate.
This allows us to examine additional detailed logs emitted by third party crates
that use `tracing` crate for logging by setting `RUST_LOG` env var or passing
`-L` option in command line.
Closes #25045
PrismJS uses `WorkerGlobalScope` and `self` for detecting browser's Web
Worker context:
59e5a34713/prism.js (L11)
Now the detection logic above is broken when it's imported from Deno's
Web Worker context because we only hide `self` (Prism assumes when
`WorkerGlobalScope` is available, `self` is also available).
This change fixes the above by also hiding `WorkerGlobalScope` global in
Node compat mode.
closes #25008
This change improves the Node.js compatibility in managed npm resolution
mode by disabling the discovery of `node_modules` when the
main specifier is inside of `DENO_DIR`.
closes #22732
closes #24589
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
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.
This makes bare specifiers for npm packages work when inside a
workspace, which emulates the same behaviour as when there's a
node_modules directory. The bare specifier can be overwritten by
specifying an import map entry or package.json dependency entry.
* https://github.com/denoland/deno_config/pull/88
Closes #24605
