setup-ts-deep-modules

Configure dependency-cruiser to restrict TypeScript imports to package entry points.

Updated Apr 8, 2026
One-click install
npx skills add https://github.com/tonomb/personal-pnl --skill setup-ts-deep-modules-tonomb
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: setup-ts-deep-modules
Source: https://github.com/tonomb/personal-pnl/tree/main/.agents/skills/setup-ts-deep-modules
Command: npx skills add https://github.com/tonomb/personal-pnl --skill setup-ts-deep-modules-tonomb

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires dependency-cruiser.

What problem does it solve?

This skill prevents architectural decay in TypeScript monorepos by enforcing deep module boundaries, ensuring that internal implementation details remain hidden and inaccessible from outside a package.

Core Features & Use Cases

  • Boundary Enforcement: Automatically installs and configures dependency-cruiser to block deep imports into package subfolders.
  • Standardized Structure: Promotes a consistent layout where only root-level files serve as public entry points.
  • Use Case: Use this to prevent developers from accidentally importing internal utility functions from another package, forcing them to use the defined public API instead.

Quick Start

Run the setup-ts-deep-modules skill to configure dependency-cruiser and enforce deep module boundaries in this repository.

Frequently Asked Questions about setup-ts-deep-modules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce architectural boundaries and prevent deep imports in a TypeScript monorepo?

Enforce architectural boundaries in a TypeScript monorepo by configuring dependency-cruiser to restrict imports exclusively to package entry points, blocking access to internal subfolders like lib or tests.

What is the best way to detect circular dependencies and manage the public surface area in TS packages?

Managing public surface area in TS packages requires automated linting via dependency-cruiser to detect circular dependencies and ensure only root-level files serve as the public API.

Does dependency-cruiser work for encapsulating internal logic within multi-package TypeScript projects?

Yes, dependency-cruiser encapsulates internal logic within multi-package TypeScript projects by enforcing strict module boundaries that hide implementation details and prevent external packages from importing them.

How do I set up linting rules to stop developers from importing internal utility functions from another package?

Set up linting rules to prevent importing internal utilities by running an automated configuration that standardizes package layout and blocks deep imports into other packages' subfolders.

When should I not use deep module boundary enforcement in my architecture?

Avoid deep module boundary enforcement in single-package projects or architectures that do not follow a standardized multi-package layout, as restricting imports to entry points requires consistent folder structures.