2024-01-01 14:58:21 -05:00
|
|
|
// Copyright 2018-2024 the Deno authors. All rights reserved. MIT license.
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2023-03-11 11:43:45 -05:00
|
|
|
use std::collections::HashSet;
|
2024-01-10 17:40:30 -05:00
|
|
|
use std::collections::VecDeque;
|
2022-09-02 10:54:40 -04:00
|
|
|
use std::sync::Arc;
|
|
|
|
|
|
|
|
use deno_ast::MediaType;
|
|
|
|
use deno_ast::ModuleSpecifier;
|
|
|
|
use deno_core::error::AnyError;
|
2023-02-22 14:15:25 -05:00
|
|
|
use deno_graph::Module;
|
2023-02-09 22:00:23 -05:00
|
|
|
use deno_graph::ModuleGraph;
|
2023-04-24 19:44:35 -04:00
|
|
|
use deno_runtime::deno_node::NodeResolver;
|
2024-02-07 11:25:14 -05:00
|
|
|
use deno_terminal::colors;
|
2022-09-02 10:54:40 -04:00
|
|
|
use once_cell::sync::Lazy;
|
|
|
|
use regex::Regex;
|
|
|
|
|
2024-09-04 11:39:30 -04:00
|
|
|
use crate::args::check_warn_tsconfig;
|
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
|
|
|
use crate::args::CheckFlags;
|
2023-04-14 18:05:46 -04:00
|
|
|
use crate::args::CliOptions;
|
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
|
|
|
use crate::args::Flags;
|
2022-09-02 10:54:40 -04:00
|
|
|
use crate::args::TsConfig;
|
2023-04-14 18:05:46 -04:00
|
|
|
use crate::args::TsConfigType;
|
|
|
|
use crate::args::TsTypeLib;
|
2022-09-02 10:54:40 -04:00
|
|
|
use crate::args::TypeCheckMode;
|
2024-05-29 14:38:18 -04:00
|
|
|
use crate::cache::CacheDBHash;
|
2023-04-14 18:05:46 -04:00
|
|
|
use crate::cache::Caches;
|
2022-09-02 10:54:40 -04:00
|
|
|
use crate::cache::FastInsecureHasher;
|
|
|
|
use crate::cache::TypeCheckCache;
|
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
|
|
|
use crate::factory::CliFactory;
|
2024-02-20 16:29:57 -05:00
|
|
|
use crate::graph_util::BuildFastCheckGraphOptions;
|
|
|
|
use crate::graph_util::ModuleGraphBuilder;
|
2023-04-21 21:02:46 -04:00
|
|
|
use crate::npm::CliNpmResolver;
|
2022-09-02 10:54:40 -04:00
|
|
|
use crate::tsc;
|
2024-01-10 17:40:30 -05:00
|
|
|
use crate::tsc::Diagnostics;
|
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
|
|
|
use crate::util::extract;
|
2024-05-28 09:34:57 -04:00
|
|
|
use crate::util::path::to_percent_decoded_str;
|
2022-09-02 10:54:40 -04:00
|
|
|
|
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
|
|
|
pub async fn check(
|
|
|
|
flags: Arc<Flags>,
|
|
|
|
check_flags: CheckFlags,
|
|
|
|
) -> Result<(), AnyError> {
|
|
|
|
let factory = CliFactory::from_flags(flags);
|
|
|
|
|
|
|
|
let main_graph_container = factory.main_module_graph_container().await?;
|
|
|
|
|
|
|
|
let specifiers =
|
|
|
|
main_graph_container.collect_specifiers(&check_flags.files)?;
|
|
|
|
if specifiers.is_empty() {
|
|
|
|
log::warn!("{} No matching files found.", colors::yellow("Warning"));
|
|
|
|
}
|
|
|
|
|
|
|
|
let specifiers_for_typecheck = if check_flags.doc || check_flags.doc_only {
|
|
|
|
let file_fetcher = factory.file_fetcher()?;
|
2024-09-25 21:50:54 -04:00
|
|
|
let root_permissions = factory.root_permissions_container()?;
|
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
|
|
|
|
|
|
|
let mut specifiers_for_typecheck = if check_flags.doc {
|
|
|
|
specifiers.clone()
|
|
|
|
} else {
|
|
|
|
vec![]
|
|
|
|
};
|
|
|
|
|
|
|
|
for s in specifiers {
|
2024-09-25 21:50:54 -04:00
|
|
|
let file = file_fetcher.fetch(&s, root_permissions).await?;
|
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
|
|
|
let snippet_files = extract::extract_snippet_files(file)?;
|
|
|
|
for snippet_file in snippet_files {
|
|
|
|
specifiers_for_typecheck.push(snippet_file.specifier.clone());
|
|
|
|
file_fetcher.insert_memory_files(snippet_file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
specifiers_for_typecheck
|
|
|
|
} else {
|
|
|
|
specifiers
|
|
|
|
};
|
|
|
|
|
|
|
|
main_graph_container
|
2024-09-18 15:15:13 -04:00
|
|
|
.check_specifiers(&specifiers_for_typecheck, None)
|
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
|
|
|
.await
|
|
|
|
}
|
|
|
|
|
2022-09-02 10:54:40 -04:00
|
|
|
/// Options for performing a check of a module graph. Note that the decision to
|
|
|
|
/// emit or not is determined by the `ts_config` settings.
|
|
|
|
pub struct CheckOptions {
|
2024-02-20 16:29:57 -05:00
|
|
|
/// Whether to build the fast check type graph if necessary.
|
|
|
|
///
|
|
|
|
/// Note: For perf reasons, the fast check type graph is only
|
|
|
|
/// built if type checking is necessary.
|
|
|
|
pub build_fast_check_graph: bool,
|
2023-04-14 18:05:46 -04:00
|
|
|
/// Default type library to type check with.
|
|
|
|
pub lib: TsTypeLib,
|
|
|
|
/// Whether to log about any ignored compiler options.
|
|
|
|
pub log_ignored_options: bool,
|
2022-09-02 10:54:40 -04:00
|
|
|
/// If true, valid `.tsbuildinfo` files will be ignored and type checking
|
|
|
|
/// will always occur.
|
|
|
|
pub reload: bool,
|
2024-02-21 08:35:25 -05:00
|
|
|
/// Mode to type check with.
|
|
|
|
pub type_check_mode: TypeCheckMode,
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
pub struct TypeChecker {
|
|
|
|
caches: Arc<Caches>,
|
|
|
|
cli_options: Arc<CliOptions>,
|
2024-02-20 16:29:57 -05:00
|
|
|
module_graph_builder: Arc<ModuleGraphBuilder>,
|
2023-04-24 19:44:35 -04:00
|
|
|
node_resolver: Arc<NodeResolver>,
|
2023-09-29 09:26:25 -04:00
|
|
|
npm_resolver: Arc<dyn CliNpmResolver>,
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
impl TypeChecker {
|
|
|
|
pub fn new(
|
|
|
|
caches: Arc<Caches>,
|
|
|
|
cli_options: Arc<CliOptions>,
|
2024-02-20 16:29:57 -05:00
|
|
|
module_graph_builder: Arc<ModuleGraphBuilder>,
|
2023-04-24 19:44:35 -04:00
|
|
|
node_resolver: Arc<NodeResolver>,
|
2023-09-29 09:26:25 -04:00
|
|
|
npm_resolver: Arc<dyn CliNpmResolver>,
|
2023-04-14 18:05:46 -04:00
|
|
|
) -> Self {
|
|
|
|
Self {
|
|
|
|
caches,
|
|
|
|
cli_options,
|
2024-02-20 16:29:57 -05:00
|
|
|
module_graph_builder,
|
2023-04-17 15:36:23 -04:00
|
|
|
node_resolver,
|
2023-04-14 18:05:46 -04:00
|
|
|
npm_resolver,
|
|
|
|
}
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
/// Type check the module graph.
|
|
|
|
///
|
|
|
|
/// It is expected that it is determined if a check and/or emit is validated
|
|
|
|
/// before the function is called.
|
|
|
|
pub async fn check(
|
|
|
|
&self,
|
2024-02-20 16:29:57 -05:00
|
|
|
graph: ModuleGraph,
|
2023-04-14 18:05:46 -04:00
|
|
|
options: CheckOptions,
|
2024-02-20 16:29:57 -05:00
|
|
|
) -> Result<Arc<ModuleGraph>, AnyError> {
|
2024-09-14 06:58:47 -04:00
|
|
|
let (graph, mut diagnostics) =
|
|
|
|
self.check_diagnostics(graph, options).await?;
|
|
|
|
diagnostics.emit_warnings();
|
2024-01-10 17:40:30 -05:00
|
|
|
if diagnostics.is_empty() {
|
2024-02-20 16:29:57 -05:00
|
|
|
Ok(graph)
|
2024-01-10 17:40:30 -05:00
|
|
|
} else {
|
|
|
|
Err(diagnostics.into())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Type check the module graph returning its diagnostics.
|
|
|
|
///
|
|
|
|
/// It is expected that it is determined if a check and/or emit is validated
|
|
|
|
/// before the function is called.
|
|
|
|
pub async fn check_diagnostics(
|
|
|
|
&self,
|
2024-02-20 16:29:57 -05:00
|
|
|
mut graph: ModuleGraph,
|
2024-01-10 17:40:30 -05:00
|
|
|
options: CheckOptions,
|
2024-02-20 16:29:57 -05:00
|
|
|
) -> Result<(Arc<ModuleGraph>, Diagnostics), AnyError> {
|
2024-03-01 10:54:46 -05:00
|
|
|
if !options.type_check_mode.is_true() || graph.roots.is_empty() {
|
2024-02-20 16:29:57 -05:00
|
|
|
return Ok((graph.into(), Default::default()));
|
2024-01-13 16:06:18 -05:00
|
|
|
}
|
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
// node built-in specifiers use the @types/node package to determine
|
|
|
|
// types, so inject that now (the caller should do this after the lockfile
|
|
|
|
// has been written)
|
2023-09-29 09:26:25 -04:00
|
|
|
if let Some(npm_resolver) = self.npm_resolver.as_managed() {
|
|
|
|
if graph.has_node_specifier {
|
|
|
|
npm_resolver.inject_synthetic_types_node_package().await?;
|
|
|
|
}
|
2023-04-14 18:05:46 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
log::debug!("Type checking.");
|
|
|
|
let ts_config_result = self
|
|
|
|
.cli_options
|
|
|
|
.resolve_ts_config_for_emit(TsConfigType::Check { lib: options.lib })?;
|
|
|
|
if options.log_ignored_options {
|
2024-09-04 11:39:30 -04:00
|
|
|
check_warn_tsconfig(&ts_config_result);
|
2023-04-14 18:05:46 -04:00
|
|
|
}
|
|
|
|
|
2024-02-21 08:35:25 -05:00
|
|
|
let type_check_mode = options.type_check_mode;
|
2023-04-14 18:05:46 -04:00
|
|
|
let ts_config = ts_config_result.ts_config;
|
2023-10-03 19:05:06 -04:00
|
|
|
let maybe_check_hash = match self.npm_resolver.check_state_hash() {
|
|
|
|
Some(npm_check_hash) => {
|
|
|
|
match get_check_hash(
|
|
|
|
&graph,
|
|
|
|
npm_check_hash,
|
|
|
|
type_check_mode,
|
|
|
|
&ts_config,
|
|
|
|
) {
|
2024-02-20 16:29:57 -05:00
|
|
|
CheckHashResult::NoFiles => {
|
|
|
|
return Ok((graph.into(), Default::default()))
|
|
|
|
}
|
2023-10-03 19:05:06 -04:00
|
|
|
CheckHashResult::Hash(hash) => Some(hash),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
None => None, // we can't determine a check hash
|
2023-04-14 18:05:46 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
// do not type check if we know this is type checked
|
2024-02-20 16:29:57 -05:00
|
|
|
let cache = TypeCheckCache::new(self.caches.type_checking_cache_db());
|
2023-10-03 19:05:06 -04:00
|
|
|
if !options.reload {
|
|
|
|
if let Some(check_hash) = maybe_check_hash {
|
|
|
|
if cache.has_check_hash(check_hash) {
|
2024-02-20 16:29:57 -05:00
|
|
|
log::debug!("Already type checked.");
|
|
|
|
return Ok((graph.into(), Default::default()));
|
2023-10-03 19:05:06 -04:00
|
|
|
}
|
|
|
|
}
|
2023-04-14 18:05:46 -04:00
|
|
|
}
|
|
|
|
|
2023-02-09 22:00:23 -05:00
|
|
|
for root in &graph.roots {
|
2023-01-04 07:20:36 -05:00
|
|
|
let root_str = root.as_str();
|
2024-05-28 09:34:57 -04:00
|
|
|
log::info!(
|
|
|
|
"{} {}",
|
|
|
|
colors::green("Check"),
|
|
|
|
to_percent_decoded_str(root_str)
|
|
|
|
);
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
2023-02-09 22:00:23 -05:00
|
|
|
|
2024-02-20 16:29:57 -05:00
|
|
|
let check_js = ts_config.get_check_js();
|
2023-04-14 18:05:46 -04:00
|
|
|
// while there might be multiple roots, we can't "merge" the build info, so we
|
|
|
|
// try to retrieve the build info for first root, which is the most common use
|
|
|
|
// case.
|
|
|
|
let maybe_tsbuildinfo = if options.reload {
|
|
|
|
None
|
|
|
|
} else {
|
|
|
|
cache.get_tsbuildinfo(&graph.roots[0])
|
|
|
|
};
|
|
|
|
// to make tsc build info work, we need to consistently hash modules, so that
|
|
|
|
// tsc can better determine if an emit is still valid or not, so we provide
|
|
|
|
// that data here.
|
2024-05-29 14:38:18 -04:00
|
|
|
let hash_data = FastInsecureHasher::new_deno_versioned()
|
2023-07-10 17:45:09 -04:00
|
|
|
.write(&ts_config.as_bytes())
|
|
|
|
.finish();
|
2023-04-14 18:05:46 -04:00
|
|
|
|
2024-02-20 16:29:57 -05:00
|
|
|
// add fast check to the graph before getting the roots
|
|
|
|
if options.build_fast_check_graph {
|
|
|
|
self.module_graph_builder.build_fast_check_graph(
|
|
|
|
&mut graph,
|
|
|
|
BuildFastCheckGraphOptions {
|
2024-07-03 20:54:33 -04:00
|
|
|
workspace_fast_check: deno_graph::WorkspaceFastCheckOption::Disabled,
|
2024-02-20 16:29:57 -05:00
|
|
|
},
|
|
|
|
)?;
|
|
|
|
}
|
|
|
|
|
|
|
|
let root_names = get_tsc_roots(&graph, check_js);
|
|
|
|
let graph = Arc::new(graph);
|
2023-04-14 18:05:46 -04:00
|
|
|
let response = tsc::exec(tsc::Request {
|
|
|
|
config: ts_config,
|
2024-02-20 16:29:57 -05:00
|
|
|
debug: self.cli_options.log_level() == Some(log::Level::Debug),
|
2023-04-14 18:05:46 -04:00
|
|
|
graph: graph.clone(),
|
|
|
|
hash_data,
|
2023-09-28 16:43:45 -04:00
|
|
|
maybe_npm: Some(tsc::RequestNpmState {
|
|
|
|
node_resolver: self.node_resolver.clone(),
|
|
|
|
npm_resolver: self.npm_resolver.clone(),
|
|
|
|
}),
|
2023-04-14 18:05:46 -04:00
|
|
|
maybe_tsbuildinfo,
|
|
|
|
root_names,
|
|
|
|
check_mode: type_check_mode,
|
|
|
|
})?;
|
|
|
|
|
2024-03-31 16:39:40 -04:00
|
|
|
let mut diagnostics = response.diagnostics.filter(|d| {
|
|
|
|
if self.is_remote_diagnostic(d) {
|
|
|
|
type_check_mode == TypeCheckMode::All && d.include_when_remote()
|
|
|
|
} else {
|
|
|
|
true
|
|
|
|
}
|
|
|
|
});
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2024-01-10 17:40:30 -05:00
|
|
|
diagnostics.apply_fast_check_source_maps(&graph);
|
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
if let Some(tsbuildinfo) = response.maybe_tsbuildinfo {
|
|
|
|
cache.set_tsbuildinfo(&graph.roots[0], &tsbuildinfo);
|
|
|
|
}
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
if diagnostics.is_empty() {
|
2023-10-03 19:05:06 -04:00
|
|
|
if let Some(check_hash) = maybe_check_hash {
|
|
|
|
cache.add_check_hash(check_hash);
|
|
|
|
}
|
2023-04-14 18:05:46 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
log::debug!("{}", response.stats);
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2024-02-20 16:29:57 -05:00
|
|
|
Ok((graph, diagnostics))
|
2023-04-14 18:05:46 -04:00
|
|
|
}
|
2024-03-31 16:39:40 -04:00
|
|
|
|
|
|
|
fn is_remote_diagnostic(&self, d: &tsc::Diagnostic) -> bool {
|
|
|
|
let Some(file_name) = &d.file_name else {
|
|
|
|
return false;
|
|
|
|
};
|
|
|
|
if file_name.starts_with("https://") || file_name.starts_with("http://") {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
// check if in an npm package
|
|
|
|
let Ok(specifier) = ModuleSpecifier::parse(file_name) else {
|
|
|
|
return false;
|
|
|
|
};
|
|
|
|
self.node_resolver.in_npm_package(&specifier)
|
|
|
|
}
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
enum CheckHashResult {
|
2024-05-29 14:38:18 -04:00
|
|
|
Hash(CacheDBHash),
|
2022-09-02 10:54:40 -04:00
|
|
|
NoFiles,
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Gets a hash of the inputs for type checking. This can then
|
|
|
|
/// be used to tell
|
|
|
|
fn get_check_hash(
|
2023-02-09 22:00:23 -05:00
|
|
|
graph: &ModuleGraph,
|
2023-10-03 19:05:06 -04:00
|
|
|
package_reqs_hash: u64,
|
2023-04-14 18:05:46 -04:00
|
|
|
type_check_mode: TypeCheckMode,
|
|
|
|
ts_config: &TsConfig,
|
2022-09-02 10:54:40 -04:00
|
|
|
) -> CheckHashResult {
|
2024-05-29 14:38:18 -04:00
|
|
|
let mut hasher = FastInsecureHasher::new_deno_versioned();
|
2023-04-14 18:05:46 -04:00
|
|
|
hasher.write_u8(match type_check_mode {
|
2022-09-02 10:54:40 -04:00
|
|
|
TypeCheckMode::All => 0,
|
|
|
|
TypeCheckMode::Local => 1,
|
|
|
|
TypeCheckMode::None => 2,
|
|
|
|
});
|
2023-04-14 18:05:46 -04:00
|
|
|
hasher.write(&ts_config.as_bytes());
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2023-04-14 18:05:46 -04:00
|
|
|
let check_js = ts_config.get_check_js();
|
2022-09-02 10:54:40 -04:00
|
|
|
let mut has_file = false;
|
|
|
|
let mut has_file_to_type_check = false;
|
2023-07-26 17:23:07 -04:00
|
|
|
// this iterator of modules is already deterministic, so no need to sort it
|
|
|
|
for module in graph.modules() {
|
2023-02-22 14:15:25 -05:00
|
|
|
match module {
|
2024-01-31 22:15:22 -05:00
|
|
|
Module::Js(module) => {
|
2023-02-22 14:15:25 -05:00
|
|
|
let ts_check = has_ts_check(module.media_type, &module.source);
|
|
|
|
if ts_check {
|
|
|
|
has_file_to_type_check = true;
|
|
|
|
}
|
2023-02-09 22:00:23 -05:00
|
|
|
|
2023-02-22 14:15:25 -05:00
|
|
|
match module.media_type {
|
|
|
|
MediaType::TypeScript
|
|
|
|
| MediaType::Dts
|
|
|
|
| MediaType::Dmts
|
|
|
|
| MediaType::Dcts
|
|
|
|
| MediaType::Mts
|
|
|
|
| MediaType::Cts
|
|
|
|
| MediaType::Tsx => {
|
|
|
|
has_file = true;
|
|
|
|
has_file_to_type_check = true;
|
|
|
|
}
|
|
|
|
MediaType::JavaScript
|
|
|
|
| MediaType::Mjs
|
|
|
|
| MediaType::Cjs
|
|
|
|
| MediaType::Jsx => {
|
|
|
|
has_file = true;
|
|
|
|
if !check_js && !ts_check {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
MediaType::Json
|
|
|
|
| MediaType::TsBuildInfo
|
|
|
|
| MediaType::SourceMap
|
|
|
|
| MediaType::Wasm
|
|
|
|
| MediaType::Unknown => continue,
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
2023-02-22 14:15:25 -05:00
|
|
|
|
|
|
|
hasher.write_str(module.specifier.as_str());
|
2024-02-21 08:35:25 -05:00
|
|
|
hasher.write_str(
|
|
|
|
// the fast check module will only be set when publishing
|
|
|
|
module
|
|
|
|
.fast_check_module()
|
|
|
|
.map(|s| s.source.as_ref())
|
|
|
|
.unwrap_or(&module.source),
|
|
|
|
);
|
2023-02-22 14:15:25 -05:00
|
|
|
}
|
2023-07-26 17:23:07 -04:00
|
|
|
Module::Node(_) => {
|
|
|
|
// the @types/node package will be in the resolved
|
|
|
|
// snapshot below so don't bother including it here
|
|
|
|
}
|
|
|
|
Module::Npm(_) => {
|
|
|
|
// don't bother adding this specifier to the hash
|
|
|
|
// because what matters is the resolved npm snapshot,
|
|
|
|
// which is hashed below
|
|
|
|
}
|
|
|
|
Module::Json(module) => {
|
|
|
|
has_file_to_type_check = true;
|
|
|
|
hasher.write_str(module.specifier.as_str());
|
|
|
|
hasher.write_str(&module.source);
|
|
|
|
}
|
|
|
|
Module::External(module) => {
|
|
|
|
hasher.write_str(module.specifier.as_str());
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-10-03 19:05:06 -04:00
|
|
|
hasher.write_hashable(package_reqs_hash);
|
2023-07-26 17:23:07 -04:00
|
|
|
|
2022-09-02 10:54:40 -04:00
|
|
|
if !has_file || !check_js && !has_file_to_type_check {
|
|
|
|
// no files to type check
|
|
|
|
CheckHashResult::NoFiles
|
|
|
|
} else {
|
2024-05-29 14:38:18 -04:00
|
|
|
CheckHashResult::Hash(CacheDBHash::new(hasher.finish()))
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Transform the graph into root specifiers that we can feed `tsc`. We have to
|
|
|
|
/// provide the media type for root modules because `tsc` does not "resolve" the
|
|
|
|
/// media type like other modules, as well as a root specifier needs any
|
|
|
|
/// redirects resolved. We need to include all the emittable files in
|
|
|
|
/// the roots, so they get type checked and optionally emitted,
|
|
|
|
/// otherwise they would be ignored if only imported into JavaScript.
|
|
|
|
fn get_tsc_roots(
|
2023-02-09 22:00:23 -05:00
|
|
|
graph: &ModuleGraph,
|
2022-09-02 10:54:40 -04:00
|
|
|
check_js: bool,
|
|
|
|
) -> Vec<(ModuleSpecifier, MediaType)> {
|
2023-03-11 11:43:45 -05:00
|
|
|
fn maybe_get_check_entry(
|
|
|
|
module: &deno_graph::Module,
|
|
|
|
check_js: bool,
|
|
|
|
) -> Option<(ModuleSpecifier, MediaType)> {
|
|
|
|
match module {
|
2024-01-31 22:15:22 -05:00
|
|
|
Module::Js(module) => match module.media_type {
|
2023-03-11 11:43:45 -05:00
|
|
|
MediaType::TypeScript
|
|
|
|
| MediaType::Tsx
|
|
|
|
| MediaType::Mts
|
|
|
|
| MediaType::Cts
|
|
|
|
| MediaType::Dts
|
|
|
|
| MediaType::Dmts
|
2023-07-27 14:09:02 -04:00
|
|
|
| MediaType::Dcts => {
|
|
|
|
Some((module.specifier.clone(), module.media_type))
|
|
|
|
}
|
|
|
|
MediaType::JavaScript
|
|
|
|
| MediaType::Mjs
|
|
|
|
| MediaType::Cjs
|
|
|
|
| MediaType::Jsx => {
|
2023-03-11 11:43:45 -05:00
|
|
|
if check_js || has_ts_check(module.media_type, &module.source) {
|
|
|
|
Some((module.specifier.clone(), module.media_type))
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
}
|
|
|
|
}
|
|
|
|
MediaType::Json
|
|
|
|
| MediaType::Wasm
|
|
|
|
| MediaType::TsBuildInfo
|
|
|
|
| MediaType::SourceMap
|
|
|
|
| MediaType::Unknown => None,
|
|
|
|
},
|
|
|
|
Module::External(_)
|
|
|
|
| Module::Node(_)
|
|
|
|
| Module::Npm(_)
|
|
|
|
| Module::Json(_) => None,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-21 11:46:40 -04:00
|
|
|
let mut result = Vec::with_capacity(graph.specifiers_count());
|
2023-02-22 14:15:25 -05:00
|
|
|
if graph.has_node_specifier {
|
2023-01-24 09:05:54 -05:00
|
|
|
// inject a specifier that will resolve node types
|
|
|
|
result.push((
|
|
|
|
ModuleSpecifier::parse("asset:///node_types.d.ts").unwrap(),
|
|
|
|
MediaType::Dts,
|
|
|
|
));
|
|
|
|
}
|
2023-03-11 11:43:45 -05:00
|
|
|
|
2024-01-10 17:40:30 -05:00
|
|
|
let mut seen =
|
|
|
|
HashSet::with_capacity(graph.imports.len() + graph.specifiers_count());
|
|
|
|
let mut pending = VecDeque::new();
|
2023-03-11 11:43:45 -05:00
|
|
|
|
|
|
|
// put in the global types first so that they're resolved before anything else
|
|
|
|
for import in graph.imports.values() {
|
|
|
|
for dep in import.dependencies.values() {
|
|
|
|
let specifier = dep.get_type().or_else(|| dep.get_code());
|
|
|
|
if let Some(specifier) = &specifier {
|
2024-01-10 17:40:30 -05:00
|
|
|
let specifier = graph.resolve(specifier);
|
|
|
|
if seen.insert(specifier.clone()) {
|
|
|
|
pending.push_back(specifier);
|
2023-02-22 14:15:25 -05:00
|
|
|
}
|
2023-02-09 22:00:23 -05:00
|
|
|
}
|
2023-03-11 11:43:45 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// then the roots
|
|
|
|
for root in &graph.roots {
|
2024-01-10 17:40:30 -05:00
|
|
|
let specifier = graph.resolve(root);
|
|
|
|
if seen.insert(specifier.clone()) {
|
|
|
|
pending.push_back(specifier);
|
2023-03-11 11:43:45 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-01-10 17:40:30 -05:00
|
|
|
// now walk the graph that only includes the fast check dependencies
|
|
|
|
while let Some(specifier) = pending.pop_front() {
|
2024-08-30 17:12:13 -04:00
|
|
|
let Some(module) = graph.get(specifier) else {
|
2024-01-10 17:40:30 -05:00
|
|
|
continue;
|
|
|
|
};
|
|
|
|
if let Some(entry) = maybe_get_check_entry(module, check_js) {
|
|
|
|
result.push(entry);
|
|
|
|
}
|
2024-01-31 22:15:22 -05:00
|
|
|
if let Some(module) = module.js() {
|
2024-01-10 17:40:30 -05:00
|
|
|
let deps = module.dependencies_prefer_fast_check();
|
|
|
|
for dep in deps.values() {
|
|
|
|
// walk both the code and type dependencies
|
|
|
|
if let Some(specifier) = dep.get_code() {
|
|
|
|
let specifier = graph.resolve(specifier);
|
|
|
|
if seen.insert(specifier.clone()) {
|
|
|
|
pending.push_back(specifier);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if let Some(specifier) = dep.get_type() {
|
|
|
|
let specifier = graph.resolve(specifier);
|
|
|
|
if seen.insert(specifier.clone()) {
|
|
|
|
pending.push_back(specifier);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Some(dep) = module
|
|
|
|
.maybe_types_dependency
|
|
|
|
.as_ref()
|
|
|
|
.and_then(|d| d.dependency.ok())
|
|
|
|
{
|
|
|
|
let specifier = graph.resolve(&dep.specifier);
|
|
|
|
if seen.insert(specifier.clone()) {
|
|
|
|
pending.push_back(specifier);
|
|
|
|
}
|
|
|
|
}
|
2023-03-11 11:43:45 -05:00
|
|
|
}
|
2024-01-10 17:40:30 -05:00
|
|
|
}
|
2023-03-21 11:46:40 -04:00
|
|
|
|
2023-01-24 09:05:54 -05:00
|
|
|
result
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Matches the `@ts-check` pragma.
|
|
|
|
static TS_CHECK_RE: Lazy<Regex> =
|
2023-04-12 21:08:01 -04:00
|
|
|
lazy_regex::lazy_regex!(r#"(?i)^\s*@ts-check(?:\s+|$)"#);
|
2022-09-02 10:54:40 -04:00
|
|
|
|
2023-02-22 14:15:25 -05:00
|
|
|
fn has_ts_check(media_type: MediaType, file_text: &str) -> bool {
|
2022-09-02 10:54:40 -04:00
|
|
|
match &media_type {
|
|
|
|
MediaType::JavaScript
|
|
|
|
| MediaType::Mjs
|
|
|
|
| MediaType::Cjs
|
|
|
|
| MediaType::Jsx => get_leading_comments(file_text)
|
|
|
|
.iter()
|
|
|
|
.any(|text| TS_CHECK_RE.is_match(text)),
|
2023-02-22 14:15:25 -05:00
|
|
|
MediaType::TypeScript
|
|
|
|
| MediaType::Mts
|
|
|
|
| MediaType::Cts
|
|
|
|
| MediaType::Dts
|
|
|
|
| MediaType::Dcts
|
|
|
|
| MediaType::Dmts
|
|
|
|
| MediaType::Tsx
|
|
|
|
| MediaType::Json
|
|
|
|
| MediaType::Wasm
|
|
|
|
| MediaType::TsBuildInfo
|
|
|
|
| MediaType::SourceMap
|
|
|
|
| MediaType::Unknown => false,
|
2022-09-02 10:54:40 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn get_leading_comments(file_text: &str) -> Vec<String> {
|
|
|
|
let mut chars = file_text.chars().peekable();
|
|
|
|
|
|
|
|
// skip over the shebang
|
|
|
|
if file_text.starts_with("#!") {
|
|
|
|
// skip until the end of the line
|
|
|
|
for c in chars.by_ref() {
|
|
|
|
if c == '\n' {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut results = Vec::new();
|
|
|
|
// now handle the comments
|
|
|
|
while chars.peek().is_some() {
|
|
|
|
// skip over any whitespace
|
|
|
|
while chars
|
|
|
|
.peek()
|
|
|
|
.map(|c| char::is_whitespace(*c))
|
|
|
|
.unwrap_or(false)
|
|
|
|
{
|
|
|
|
chars.next();
|
|
|
|
}
|
|
|
|
|
|
|
|
if chars.next() != Some('/') {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
match chars.next() {
|
|
|
|
Some('/') => {
|
|
|
|
let mut text = String::new();
|
|
|
|
for c in chars.by_ref() {
|
|
|
|
if c == '\n' {
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
text.push(c);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
results.push(text);
|
|
|
|
}
|
|
|
|
Some('*') => {
|
|
|
|
let mut text = String::new();
|
|
|
|
while let Some(c) = chars.next() {
|
|
|
|
if c == '*' && chars.peek() == Some(&'/') {
|
|
|
|
chars.next();
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
text.push(c);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
results.push(text);
|
|
|
|
}
|
|
|
|
_ => break,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
results
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod test {
|
|
|
|
use deno_ast::MediaType;
|
|
|
|
|
|
|
|
use super::get_leading_comments;
|
|
|
|
use super::has_ts_check;
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn get_leading_comments_test() {
|
|
|
|
assert_eq!(
|
|
|
|
get_leading_comments(
|
|
|
|
"#!/usr/bin/env deno\r\n// test\n/* 1 *//*2*///3\n//\n /**/ /*4 */"
|
|
|
|
),
|
|
|
|
vec![
|
|
|
|
" test".to_string(),
|
|
|
|
" 1 ".to_string(),
|
|
|
|
"2".to_string(),
|
|
|
|
"3".to_string(),
|
|
|
|
"".to_string(),
|
|
|
|
"".to_string(),
|
|
|
|
"4 ".to_string(),
|
|
|
|
]
|
|
|
|
);
|
|
|
|
assert_eq!(
|
|
|
|
get_leading_comments("//1 /* */ \na;"),
|
|
|
|
vec!["1 /* */ ".to_string(),]
|
|
|
|
);
|
|
|
|
assert_eq!(get_leading_comments("//"), vec!["".to_string()]);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn has_ts_check_test() {
|
|
|
|
assert!(has_ts_check(
|
|
|
|
MediaType::JavaScript,
|
2023-02-22 14:15:25 -05:00
|
|
|
"// @ts-check\nconsole.log(5);"
|
2022-09-02 10:54:40 -04:00
|
|
|
));
|
|
|
|
assert!(has_ts_check(
|
|
|
|
MediaType::JavaScript,
|
2023-02-22 14:15:25 -05:00
|
|
|
"// deno-lint-ignore\n// @ts-check\n"
|
2022-09-02 10:54:40 -04:00
|
|
|
));
|
|
|
|
assert!(!has_ts_check(
|
|
|
|
MediaType::JavaScript,
|
2023-02-22 14:15:25 -05:00
|
|
|
"test;\n// @ts-check\n"
|
2022-09-02 10:54:40 -04:00
|
|
|
));
|
|
|
|
assert!(!has_ts_check(
|
|
|
|
MediaType::JavaScript,
|
2023-02-22 14:15:25 -05:00
|
|
|
"// ts-check\nconsole.log(5);"
|
2022-09-02 10:54:40 -04:00
|
|
|
));
|
|
|
|
}
|
|
|
|
}
|