foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-25 15:29:32 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/tests/specs/test/doc_permission_respected/main.out

26 lines
727 B
Text
Raw Normal View History

feat(cli): evaluate code snippets in JSDoc and markdown (#25220) This commit lets `deno test --doc` command actually evaluate code snippets in JSDoc and markdown files. ## How it works 1. Extract code snippets from JSDoc or code fences 2. Convert them into pseudo files by wrapping them in `Deno.test(...)` 3. Register the pseudo files as in-memory files 4. Run type-check and evaluation We apply some magic at the step 2 - let's say we have the following file named `mod.ts` as an input: ````ts /** * ```ts * import { assertEquals } from "jsr:@std/assert/equals"; * * assertEquals(add(1, 2), 3); * ``` */ export function add(a: number, b: number) { return a + b; } ```` This is virtually transformed into: ```ts import { assertEquals } from "jsr:@std/assert/equals"; import { add } from "files:///path/to/mod.ts"; Deno.test("mod.ts$2-7.ts", async () => { assertEquals(add(1, 2), 3); }); ``` Note that a new import statement is inserted here to make `add` function available. In a nutshell, all items exported from `mod.ts` become available in the generated pseudo file with this automatic import insertion. The intention behind this design is that, from library user's standpoint, it should be very obvious that this `add` function is what this example code is attached to. Also, if there is an explicit import statement like `import { add } from "./mod.ts"`, this import path `./mod.ts` is not helpful for doc readers because they will need to import it in a different way. The automatic import insertion has some edge cases, in particular where there is a local variable in a snippet with the same name as one of the exported items. This case is addressed by employing swc's scope analysis (see test cases for more details). ## "type-checking only" mode stays around This change will likely impact a lot of existing doc tests in the ecosystem because some doc tests rely on the fact that they are not evaluated - some cause side effects if executed, some throw errors at runtime although they do pass the type check, etc. To help those tests gradually transition to the ones runnable with the new `deno test --doc`, we will keep providing the ability to run type-checking only via `deno check --doc`. Additionally there is a `--doc-only` option added to the `check` subcommand too, which is useful when you want to type-check on code snippets in markdown files, as normal `deno check` command doesn't accept markdown. ## Demo https://github.com/user-attachments/assets/47e9af73-d16e-472d-b09e-1853b9e8f5ce --- Closes #4716
2024-09-18 00:35:48 -04:00
Check [WILDCARD]/main.ts
Check [WILDCARD]/main.ts$3-6.ts
Check [WILDCARD]/main.ts$8-11.ts
running 0 tests from ./main.ts
running 1 test from ./main.ts$3-6.ts
[WILDCARD]/main.ts$3-6.ts ... ok ([WILDCARD]ms)
running 1 test from ./main.ts$8-11.ts
[WILDCARD]/main.ts$8-11.ts ... FAILED ([WILDCARD]ms)
ERRORS
[WILDCARD]/main.ts$8-11.ts => ./main.ts$8-11.ts:1:6
error: NotCapable: Requires env access to "USER", run again with the --allow-env flag
const _user = Deno.env.get("USER");
^
at Object.getEnv [as get] ([WILDCARD])
at [WILDCARD]/main.ts$8-11.ts:2:28
FAILURES
[WILDCARD]/main.ts$8-11.ts => ./main.ts$8-11.ts:1:6
FAILED | 1 passed | 1 failed ([WILDCARD]ms)
error: Test failed
Copy permalink