TGlider Compatibility
TGlider requires Node.js 24 or newer. Semantic support depends on the project configuration and TypeScript’s model of the source.
Source Forms
The installation guide preloads the workspace. Use the load tool to select another workspace later.
| Area | Current support | Notes |
|---|---|---|
.ts, .tsx | Supported | Primary TypeScript and TSX source forms, including React-style component surfaces where TypeScript can parse the file. |
.js, .jsx | Supported | Supported through JavaScript project settings, jsconfig.json, or inferred JS/TS projects. |
.mts, .cts, .mjs, .cjs | Supported | Supported where TypeScript can resolve the module mode and project ownership. |
.vue, .svelte | Not semantic targets | TGlider does not provide semantic intelligence inside non-TS single-file component formats unless their script content is exposed to TypeScript as ordinary JS/TS. |
Project Configuration
| Area | Current support | Notes |
|---|---|---|
tsconfig.json | Supported | Includes project references, baseUrl, paths, skipped-config diagnostics, and project ownership detection. |
jsconfig.json | Supported | Supported for JavaScript workspaces that rely on JS project settings. |
| Inferred JS/TS projects | Supported | Useful for smaller workspaces without explicit config files, with less project metadata than configured projects. |
| Generated directories | Best effort | Generated-looking files are filtered from some diagnostics by default; include generated files only when the workflow needs them. |
Module Systems and Exports
| Area | Current support | Notes |
|---|---|---|
| ESM import/export | Supported | Standard ESM exports and re-exports are part of symbol, structure, dependency, and API surface workflows. |
| NodeNext / Node-style resolution | Supported | TGlider follows TypeScript project settings and package type metadata where available. |
TypeScript export = | Supported | Included in export-aware tools where TypeScript can identify the exported binding. |
| Bounded CommonJS exports | Supported with caveats | Static forms such as module.exports = value, exports.name = value, and module.exports.name = value are supported when the binding can be identified. |
| Dynamic imports and runtime export mutation | Unsupported | TGlider avoids guessing dynamic runtime behavior; use explicit source inspection or runtime evidence for those cases. |
Package Managers and Workspaces
| Area | Current support | Notes |
|---|---|---|
package.json | Supported | Package metadata, package type, scripts, dependencies, and package ownership are surfaced where available. |
| npm / yarn workspaces | Supported | Workspace package patterns are used for workspace package discovery. |
| pnpm workspace YAML | Supported | Workspace package discovery understands pnpm workspace metadata. |
| Bun package-manager hints | Supported | Bun package-manager metadata is detected as workspace context. |
| Lockfile-backed dependency graph / Yarn PnP | Planned | Lockfile provenance, pnpm catalogs, Yarn PnP, and richer external package graphs are roadmap items. |
MCP Clients and Transports
Choose a client in the installation guide.
| Area | Current support | Notes |
|---|---|---|
| Local stdio | Default | The client starts one local server process. |
| Streamable HTTP | Supported | See HTTP setup for a separately managed server. |
Compatibility Notes
- TGlider uses TypeScript compiler and language-service APIs for semantic questions before falling back to structural source evidence.
- Support means TGlider can load and analyze the workspace through TypeScript project state. It is not a guarantee that every framework convention or generated artifact is semantically modeled.
- When TypeScript or package metadata cannot provide stable evidence, TGlider should report unsupported or omitted shapes rather than guessing runtime behavior.