@nx/js
Version:
75 lines (74 loc) • 4.77 kB
TypeScript
import { Tree } from '@nx/devkit';
import type * as ts from 'typescript';
export declare function readTsConfig(tsConfigPath: string, sys?: ts.ParseConfigHost): ts.ParsedCommandLine;
export declare function readTsConfigFromTree(tree: Tree, tsConfigPath: string): ts.ParsedCommandLine;
/**
* The members `createTreeParseConfigHost` overrides: the file system ones are
* backed by the `Tree`, `realpath`/`getCurrentDirectory` are anchored to
* `tree.root`, and `useCaseSensitiveFileNames` is platform-derived from
* `ts.sys`. The returned object still spreads `ts.sys` (TypeScript duck-types
* the host and reads members this type does not name), so the narrow type is a
* compile-time guard on Nx callers: everything outside it is disk-backed and
* escapes the tree.
*/
export type TreeParseConfigHost = Required<Pick<ts.ParseConfigHost, 'useCaseSensitiveFileNames' | 'readDirectory' | 'readFile' | 'fileExists' | 'directoryExists' | 'realpath' | 'getCurrentDirectory'>>;
/**
* A TypeScript host, backed by the devkit `Tree`, that resolves `extends` the
* way real `tsc` does. The naive `{ ...ts.sys, readFile: (p) => tree.read(p) }`
* host resolves less than `tsc`:
* - A package-form `extends` (e.g. `@tsconfig/node14/tsconfig.json`) is
* realpath-absolutized by TypeScript; `Tree.read`/`Tree.exists` re-root an
* absolute path under the workspace, so the base reads as nothing and its
* options silently vanish from the merged result (the failure surfaces only
* as a TS5083/TS6053 in `errors`, which callers discard).
* - An extension-less `extends` resolves against `process.cwd()` when
* existence comes from `ts.sys`; Nx never chdirs to the workspace root, so it
* resolves only when the command runs from the root.
*
* This host maps absolute paths under `tree.root` back to tree-relative for the
* tree lookups and falls through to `fs` for paths that resolve outside the
* workspace (a pnpm store or a `link:`/`file:` target). Resolution is anchored
* to `tree.root` rather than the working directory: TypeScript resolves a
* package-form base as a relative path and hands it to `realpath`, and
* `ts.sys.realpath` would resolve it against `process.cwd()`, so a workspace
* whose root is not an ancestor of the working directory would read a
* same-named package from the wrong tree.
*
* `readDirectory` is a no-op: the source-file scan is skipped because callers
* read only the merged `options`, never the file list. A config that resolves
* its inputs through `include` (or the default glob) then reports a TS18003
* unless it also carries `files` or `references`, so `errors.length > 0` is not
* a usable signal; match specific codes (TS5083/TS6053) instead.
*/
export declare function createTreeParseConfigHost(tree: Tree): TreeParseConfigHost;
/**
* Whether a `ParsedCommandLine` produced with `createTreeParseConfigHost` failed
* to resolve an `extends` target: TS5083 (the base resolved but could not be
* read) or TS6053 (the base could not be resolved at all). Because the host
* resolves what real `tsc` resolves, this only fires for a config whose extends
* chain `tsc` cannot read either. The no-op `readDirectory` also adds a TS18003
* whenever the config resolves inputs through `include` and carries neither
* `files` nor `references`, so `errors.length > 0` is not a usable signal; match
* these two codes.
*/
export declare function extendsResolutionFailed(errors: readonly ts.Diagnostic[]): boolean;
export declare function getRootTsConfigPathInTree(tree: Tree): string | null;
export declare function getRelativePathToRootTsConfig(tree: Tree, targetPath: string): string;
export declare function getRootTsConfigPath(): string | null;
export declare function getRootTsConfigFileName(tree?: Tree): string | null;
export declare function addTsConfigPath(tree: Tree, importPath: string, lookupPaths: string[]): void;
/**
* When `baseUrl` is not set and `paths` are inherited via `extends`,
* tools like `tsconfig-paths` resolve from the loaded file's directory
* instead of the file where `paths` is defined. This walks the `extends`
* chain to find the correct resolution base.
*
* Returns the directory that `paths` values should be resolved relative to.
* Walks the tsconfig `extends` chain to find where `paths` is defined, then
* looks for the applicable `baseUrl` from that point toward the root of the
* chain (ignoring child overrides that don't apply to the paths-defining
* tsconfig). When no `baseUrl` applies, returns the directory of the
* tsconfig that defines `paths`.
*/
export declare function resolvePathsBaseUrl(tsconfigPath: string): string;
export declare function readTsConfigPaths(tsConfig?: string | ts.ParsedCommandLine): ts.MapLike<string[]>;