$ show Igorkowalski94/eslint-plugin-project-structure
eslint-plugin-project-structure is a TypeScript-based ESLint plugin that enforces scalable, consistent project architecture through three configurable rules: folder-structure enforcement, file-composition constraints (e.g., `**/*.consts.ts` may only contain variables, `**/*.types.ts` only interfaces/types), and independent-modules enforcement to prevent massive dependency trees. The plugin parses all import syntaxes — ESM, CJS, dynamic `import()`, `require()`, `jest.mock()`, `jest.requireActual()`, plus `ExportAllDeclaration`/`ExportNamedDeclaration` — and validates file paths against micromatch glob patterns. Configuration is provided via JSON files validated against a bundled JSON schema, enabling IDE autocompletion and early error detection. The codebase is a standard ESLint plugin library: rules receive AST nodes and report violations, with utility modules handling import classification, cross-platform path resolution (Windows/POSIX), and multi-pattern glob matching. It is distributed as compiled CommonJS (`dist/index.js`) with a self-referencing dev dependency for integration testing. The project ships with comprehensive tests covering edge cases like Windows paths, `@types/` scoped packages, and external-import detection, plus CI running type checks, format checks, lint, and tests via Yarn 3.6.3.
The LLM identified 4 files worth highlighting for reuse:
Classifies import specifiers as external vs internal, with special handling for `@types/` scoped packages, `require()`, `import()`, `jest.mock()`, and `jest.requireActual()`. This is a self-contained, well-tested utility that solves the recurring problem of distinguishing third-party from local imports — directly extractable into any linting or dependency-analysis tool.
Resolves and normalizes file paths across Windows and POSIX, correctly detecting `node_modules` boundaries and falling back to `cwd` when appropriate. Demonstrates non-obvious cross-platform path handling (e.g., `C:/Users/...` drive-letter cases) that is a common pain point in developer tools — reusable as a standalone path utility.
Wraps micromatch with multi-pattern semantics: `pattern.some((p) => micromatch.every(input, p))`, enabling complex include/exclude rules. Also validates that referenced patterns contain exactly one pattern, producing actionable error messages. This pattern-matching layer is generic and could be extracted for any config-driven file-filtering system.
A hand-crafted JSON Schema that powers IDE autocompletion and validation for the plugin's configuration files. It encodes the full config surface (folder-structure, file-composition, independent-modules) and is referenced via `$schema` in user configs — a best-practice pattern for any developer tool exposing JSON configuration.