summaryrefslogtreecommitdiff
path: root/tests/integration/npm_tests.rs
AgeCommit message (Collapse)Author
2024-10-18fix(npm): ensure scoped package name is encoded in URLs (#26390)Marvin Hagemeister
Fixes https://github.com/denoland/deno/issues/26385
2024-09-25chore: deprecate npm itests (#25804)Mohammad Sulaiman
2024-09-20refactor(tests): migrate npm itests to specs (#25764)Satya Rohith
Towards https://github.com/denoland/deno/issues/25241
2024-09-18feat: suggest `deno install --entrypoint` instead of `deno cache` (#25228)Asher Gomez
Hides `deno cache` from `--help` output. --------- Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com> Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-09-10feat: require(esm) (#25501)snek
implement require(esm) using `op_import_sync` from deno_core. possible future changes: - cts and mts - replace Deno.core.evalContext to optimize esm syntax detection Fixes: https://github.com/denoland/deno/issues/25487
2024-09-04fix(byonm): resolve npm deps of jsr deps (#25399)David Sherret
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.
2024-08-30refactor: remove DENO_FUTURE (#25314)David Sherret
2024-08-30BREAKING: `DENO_FUTURE=1` by default, or welcome to Deno 2.0 (#25213)Bartek Iwańczuk
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>
2024-08-28feat: improve lockfile v4 to store normalized version constraints and be ↵David Sherret
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.
2024-08-28feat: remove `--lock-write` flag (#25214)Bartek Iwańczuk
This commit remove `--lock-write` that was deprecated in v1.45 release. Closes https://github.com/denoland/deno/issues/24167. --------- Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
2024-08-28fix: replace `npm install` hint with `deno install` hint (#25244)Bartek Iwańczuk
Needed for https://github.com/denoland/deno/pull/25213. With Deno 2, we should suggest using `deno install` instead of `npm install`.
2024-08-26feat: lockfile v4 by default (#25165)David Sherret
This won't be fully stabilized until 2.0 is released.
2024-08-24refactor(lsp): changes for lsp_types 0.97.0 (#25169)Nayeem Rahman
2024-08-20fix: adjust suggestion for lockfile regeneration (#25107)Bartek Iwańczuk
Ref https://github.com/denoland/deno/pull/24436#issuecomment-2288568645
2024-07-24fix(future): Emit `deno install` warning less often, suggest `deno install` ↵Nathan Whitaker
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
2024-07-24fix(node): better detection for when to surface node resolution errors (#24653)David Sherret
2024-07-18Reland "refactor(fetch): reimplement fetch with hyper instead of reqwest" ↵Bartek Iwańczuk
(#24593) Originally landed in https://github.com/denoland/deno/commit/f6fd6619e708a515831f707438368d81b0c9aa56. Reverted in https://github.com/denoland/deno/pull/24574. This reland contains a fix that sends "Accept: */*" header for calls made from "FileFetcher". Absence of this header made downloading source code from JSR broken. This is tested by ensuring this header is present in the test server that servers JSR packages. --------- Co-authored-by: Sean McArthur <sean@seanmonstar.com>
2024-07-13Revert "refactor(fetch): reimplement fetch with hyper instead of reqwest ↵Ryan Dahl
(#24237)" (#24574) This reverts commit f6fd6619e708a515831f707438368d81b0c9aa56. I'm seeing a difference between canary and 1.45.2. In `deno-docs/reference_gen` I can't download dax when running `deno task types` ``` ~/src/deno-docs/reference_gen# deno upgrade --canary Looking up latest canary version Found latest version f6fd6619e708a515831f707438368d81b0c9aa56 Downloading https://dl.deno.land/canary/f6fd6619e708a515831f707438368d81b0c9aa56/deno-aarch64-apple-darwin.zip Deno is upgrading to version f6fd6619e708a515831f707438368d81b0c9aa56 Archive: /var/folders/9v/kys6gqns6kl8nksyn4l1f9v40000gn/T/.tmpb5lDnq/deno.zip inflating: deno Upgraded successfully ~/src/deno-docs/reference_gen# deno -v deno 1.45.2+f6fd661 ~/src/deno-docs/reference_gen# rm -rf /Users/ry/Library/Caches/deno ~/src/deno-docs/reference_gen# deno task types Task types deno task types:deno && deno task types:node Task types:deno deno run --allow-read --allow-write --allow-run --allow-env --allow-sys deno-docs.ts error: JSR package manifest for '@david/dax' failed to load. expected value at line 1 column 1 at file:///Users/ry/src/deno-docs/reference_gen/deno-docs.ts:2:15 ~/src/deno-docs/reference_gen# deno upgrade --version 1.45.2 Downloading https://github.com/denoland/deno/releases/download/v1.45.2/deno-aarch64-apple-darwin.zip Deno is upgrading to version 1.45.2 Archive: /var/folders/9v/kys6gqns6kl8nksyn4l1f9v40000gn/T/.tmp3R7uhF/deno.zip inflating: deno Upgraded successfully ~/src/deno-docs/reference_gen# rm -rf /Users/ry/Library/Caches/deno ~/src/deno-docs/reference_gen# deno task types Task types deno task types:deno && deno task types:node Task types:deno deno run --allow-read --allow-write --allow-run --allow-env --allow-sys deno-docs.ts Task types:node deno run --allow-read --allow-write=. --allow-env --allow-sys node-docs.ts ```
2024-07-13refactor(fetch): reimplement fetch with hyper instead of reqwest (#24237)Sean McArthur
This commit re-implements `ext/fetch` and all dependent crates using `hyper` and `hyper-util`, instead of `reqwest`. The reasoning is that we want to have greater control and access to low level `hyper` APIs when implementing `fetch` API as well as `node:http` module. --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-07-10feat(node): Support executing npm package lifecycle scripts ↵Nathan Whitaker
(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
2024-06-26refactor: move PackageJson to deno_config (#24348)David Sherret
2024-06-11fix(npm): resolve dynamic npm imports individually (#24170)David Sherret
* https://github.com/denoland/deno_npm/pull/57 * https://github.com/denoland/deno_graph/pull/498 Closes https://github.com/denoland/deno/issues/17802
2024-06-03refactor: extract structs for downloading tarballs and npm registry ↵David Sherret
packuments (#24067)
2024-05-28feat(vendor): support modifying remote files in vendor folder without ↵David Sherret
checksum errors (#23979) Includes: * https://github.com/denoland/deno_graph/pull/486 * https://github.com/denoland/deno_graph/pull/488 * https://github.com/denoland/deno_lockfile/pull/25 * https://github.com/denoland/deno_lockfile/pull/22 * https://github.com/denoland/deno_graph/pull/483 * https://github.com/denoland/deno_graph/pull/470
2024-05-23FUTURE: initial support for .npmrc file (#23560)Bartek Iwańczuk
This commit adds initial support for ".npmrc" files. Currently we only discover ".npmrc" files next to "package.json" files and discovering these files in user home dir is left for a follow up. This pass supports "_authToken" and "_auth" configuration for providing authentication. LSP support has been left for a follow up PR. Towards https://github.com/denoland/deno/issues/16105
2024-05-23fix(cli): Support deno.lock with only package.json present + fix DENO_FUTURE ↵Nathan Whitaker
install interactions with lockfile (#23918) Fixes #23571. Previously, we required a `deno.json` to be present (or the `--lock` flag) in order for us to resolve a `deno.lock` file. This meant that if you were using deno in an npm-first project deno wouldn't use a lockfile. Additionally, while I was fixing that, I discovered there were a couple bugs keeping the future `install` command from using a lockfile. With this PR, `install` will actually resolve the lockfile (or create one if not present), and update it if it's not up-to-date. This also speeds up `deno install`, as we can use the lockfile to skip work during npm resolution.
2024-05-07chore: fix flaky net_listen_allow_localhost_4555 (#23726)David Sherret
Moves the test npm registry server port from `4558` to `426x`
2024-05-07chore(test): move npm registries to separate servers and to the ↵David Sherret
`tests/registry` folder (#23717) 1. Moves the npm registries to their own dedicated ports. 2. Moves the data files out of `tests/testdata/npm/registry` to `tests/registry/npm`.
2024-04-23test: add private npm registry (#23510)Bartek Iwańczuk
This commit adds a "private npm registry" to the test server. This registry requires to send an appropriate Authorization header. Towards https://github.com/denoland/deno/issues/16105
2024-04-03FUTURE: enable BYONM by default (#23194)Bartek Iwańczuk
When `DENO_FUTURE=1` env var is present, then BYONM ("bring your own node_modules") is enabled by default. That means that is there's a `package.json` present, users are expected to explicitly install dependencies from that file. Towards https://github.com/denoland/deno/issues/23151
2024-03-13chore: rough first pass on spec tests (#22877)David Sherret
2024-03-09fix(node): require of pkg json imports was broken (#22821)David Sherret
2024-03-08fix(node): resolve .css files in npm packages when type checking (#22804)David Sherret
When type checking, we should just resolve css files in npm packages and not surface a type checking error on the specifier.
2024-03-06fix(node): improve cjs tracking (#22673)David Sherret
We were missing saying that a file is CJS when some Deno code imported from the node_modules directory at runtime.
2024-02-15feat(unstable): single checksum per JSR package in the lockfile (#22421)David Sherret
This changes the lockfile to not store JSR specifiers in the "remote" section. Instead a single JSR integrity is stored per package in the lockfile, which is a hash of the version's `x.x.x_meta.json` file, which contains hashes for every file in the package. The hashes in this file are then compared against when loading. Additionally, when using `{ "vendor": true }` in a deno.json, the files can be modified without causing lockfile errors—the checksum is only checked when copying into the vendor folder and not afterwards (eventually we should add this behaviour for non-jsr specifiers as well). As part of this change, the `vendor` folder creation is not always automatic in the LSP and running an explicit cache command is necessary. The code required to track checksums in the LSP would have been too complex for this PR, so that all goes through deno_graph now. The vendoring is still automatic when running from the CLI.
2024-02-12chore: continue tests/ re-org (#22396)Matt Mastracci
Split `node_compat_tests` into its own top-level test so its stdout doesn't stomp on the remainder of the tests.
2024-02-10chore: move cli/tests/ -> tests/ (#22369)Matt Mastracci
This looks like a massive PR, but it's only a move from cli/tests -> tests, and updates of relative paths for files. This is the first step towards aggregate all of the integration test files under tests/, which will lead to a set of integration tests that can run without the CLI binary being built. While we could leave these tests under `cli`, it would require us to keep a more complex directory structure for the various test runners. In addition, we have a lot of complexity to ignore various test files in the `cli` project itself (cargo publish exclusion rules, autotests = false, etc). And finally, the `tests/` folder will eventually house the `test_ffi`, `test_napi` and other testing code, reducing the size of the root repo directory. For easier review, the extremely large and noisy "move" is in the first commit (with no changes -- just a move), while the remainder of the changes to actual files is in the second commit.