| Age | Commit message (Collapse) | Author |
|---|
|
Fixes https://github.com/denoland/deno/issues/26385
|
|
|
|
test`, etc) (#26075)
Fixes https://github.com/denoland/deno/issues/25533. Fixes
https://github.com/denoland/deno/issues/25396.
Previously we only supported it on `deno install` and `deno cache`,
which is annoying if you're using `nodeModulesDir: auto`.
Also changes from printing output of lifecycle scripts directly to
capturing the output and only printing it on error.
|
|
package.json (#25981)
Closes https://github.com/denoland/deno/issues/25905
|
|
|
|
See https://github.com/denoland/deno_ast/pull/278
Fixes https://github.com/denoland/deno/issues/25810
|
|
|
|
installs (#25878)
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.
|
|
`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.
|
|
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).
|
|
Towards https://github.com/denoland/deno/issues/25241
|
|
Fixes cjs modules being loaded as esm.
|
|
packages (#25694)
This commit improves warning messages for deprecated npm packages
and packages that rely on lifecycle script.
|
|
* https://github.com/denoland/deno_npm/pull/68
|
|
`--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.
|
|
(#25391)
Also rewrites some of the subcommands help text
Closes https://github.com/denoland/deno/issues/25362
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
`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
```
|
|
Towards https://github.com/denoland/deno/issues/25241
|
|
|
|
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>
|
|
|
|
The test is failing if run with `DENO_FUTURE=1` which is blocking
https://github.com/denoland/deno/pull/25213.
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
more terse (#25247)
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.
|
|
Needed for https://github.com/denoland/deno/pull/25213.
With Deno 2, we should suggest using `deno install` instead of `npm
install`.
|
|
This won't be fully stabilized until 2.0 is released.
|
|
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
|
|
Ref https://github.com/denoland/deno/pull/24436#issuecomment-2288568645
|
|
PrismJS uses `WorkerGlobalScope` and `self` for detecting browser's Web
Worker context:
https://github.com/PrismJS/prism/blob/59e5a3471377057de1f401ba38337aca27b80e03/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
|
|
Closes #23950
|
|
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
|
|
|
|
Regression from
https://github.com/denoland/deno/commit/04f9db5b2217fe06f88e76146aac6362ff0b0b86
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.
|
|
|
|
|
|
Failed in
https://github.com/denoland/deno/actions/runs/9982978127/job/27589707376
|
|
workspace (#24611)
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
|
|
respect aliases in package.json (#24609)
Fixes #24419.
|
|
We would resolve the wrong package.json, resulting in an inability to
run CJS (or other node-mode) scripts
|
|
(#24591)
Closes #24584
|
|
deno.json not in workspace (#24559)
Closes #24554
|
|
NPM inserts a default install script when a package has a `binding.gyp`
file.
It's possible, however, for the package to exclude the `binding.gyp`
file when they publish, and in this case the install script will never
succeed for a user of the package.
This happens with `fsevents`, for instance. They don't include the
`binding.gyp` file in their published tarball, but the default install
script appears in the manifest served by `npm`.
This causes us to warn that `fsevents` has an install script, but when
you try to run it it fails due to `binding.gyp` not existing.
|
|
directory (#24530)
Closes #24518
|
|
(#24492)
Closes #16370
|
|
Previously when we printed out the packages that skipped install
scripts, we didn't prefix them with `npm:`. When you pass
`--allow-scripts` though, we require `npm:`, which means you can't just
copy paste the package name from the warning message.
|
|
(preinstall/install/postinstall) (#24487)
Adds support for running npm package lifecycle scripts, opted into via a
new `--allow-scripts` flag.
With this PR, when running `deno cache` (or `DENO_FUTURE=1 deno
install`) you can specify the `--allow-scripts=pkg1,pkg2` flag to run
lifecycle scripts attached to the given packages.
Note at the moment this only works when `nodeModulesDir` is true (using
the local resolver).
When a package with un-run lifecycle scripts is encountered, we emit a
warning suggesting things may not work and to try running lifecycle
scripts. Additionally, if a package script implicitly requires
`node-gyp` and it's not found on the system, we emit a warning.
Extra things in this PR:
- Extracted out bits of `task.rs` into a separate module for reuse
- Added a couple fields to `process.config` in order to support
`node-gyp` (it relies on a few variables being there)
- Drive by fix to downloading new npm packages to test registry
---
TODO:
- [x] validation for allow-scripts args (make sure it looks like an npm
package)
- [x] make allow-scripts matching smarter
- [ ] figure out what issues this closes
---
Review notes:
- This adds a bunch of deps to our test registry due to using
`node-gyp`, so it's pretty noisy
|
|
override home dir so .npmrc on the dev machine doesn't break it
Signed-off-by: snek <snek@deno.com>
|
|
Implemented in https://github.com/denoland/deno_config/pull/74
Closes https://github.com/denoland/deno/issues/24420
|
