Skip to content

Conversation

@enki
Copy link

@enki enki commented Nov 6, 2025

Summary

Adds an exclude configuration field to sst.config.ts that allows users to specify directory patterns to skip during type generation. This prevents SST from generating sst-env.d.ts, sst.pyi, and lib/sst.rb files in unwanted locations.

Problem

SST recursively scans the entire project tree to generate type files with no way to exclude directories. This causes issues in monorepos with:

  • Git submodules in external/ or vendor/ directories
  • Test fixtures containing nested projects
  • Large dependency trees users want to ignore

Real-world example: A monorepo with submodules generates 913+ sst-env.d.ts files in ignored directories, creating noise in git status.

Solution

Add an exclude field that accepts glob patterns:

export default $config({
  app(input) {
    return {
      name: "my-app",
      exclude: ["external/**", "vendor/**", "test-*"],
    };
  },
});

Implementation

Changes Made

  1. Core Filesystem Logic (internal/fs/fs.go)

    • Added FindDownWithExcludes() with glob pattern support via filepath.Match()
    • Backward compatible: FindDown() delegates to new function with empty exclude list
    • Preserves existing node_modules and dotfile exclusions
  2. Configuration (pkg/project/project.go)

    • Added Exclude []string field to App struct
  3. Type Generation Pipeline

    • Updated all 3 generators (TypeScript, Python, Rails) to use FindDownWithExcludes()
    • Threaded exclude patterns from config through entire pipeline
  4. Comprehensive Tests (internal/fs/fs_test.go - NEW, 170 lines)

    • 8 test cases covering single/multiple patterns, globs, nested dirs
    • TDD approach: tests written first, implementation followed
    • Follows SST conventions with table-driven tests and testify/assert

Test Results

=== RUN   TestFindDown_WithExcludePatterns
--- PASS: TestFindDown_WithExcludePatterns (0.01s)
    --- PASS: TestFindDown_WithExcludePatterns/basic_-_no_excludes
    --- PASS: TestFindDown_WithExcludePatterns/exclude_node_modules
    --- PASS: TestFindDown_WithExcludePatterns/exclude_external_directory
    --- PASS: TestFindDown_WithExcludePatterns/exclude_multiple_patterns
    --- PASS: TestFindDown_WithExcludePatterns/exclude_with_glob_pattern
    --- PASS: TestFindDown_WithExcludePatterns/exclude_nested_directories
    --- PASS: TestFindDown_WithExcludePatterns/existing_node_modules_still_excluded_by_default
    --- PASS: TestFindDown_WithExcludePatterns/existing_dotfiles_still_excluded_by_default
PASS
ok      github.com/sst/sst/v3/internal/fs       0.212s

Stats

  • 8 files changed: 210 insertions(+), 11 deletions(-)
  • Fully backward compatible: No breaking changes
  • Zero new dependencies: Uses standard library filepath.Match()

Why This Matters

  • Monorepos: Essential for projects with submodules or vendor directories
  • Clean git status: No more untracked type files in ignored directories
  • Performance: Skip large dependency trees during generation
  • Industry standard: Matches patterns like .gitignore, tsconfig.exclude, Jest's testPathIgnorePatterns

Notes

This is the first test file for the internal/fs package, establishing testing patterns for filesystem operations. All existing tests continue to pass.

Add `exclude` field to sst.config.ts to prevent type generation in
specified directories. Useful for monorepos with submodules, vendor
directories, or large dependency trees.

Example usage:
```typescript
export default $config({
  app(input) {
    return {
      name: "my-app",
      exclude: ["external/**", "vendor/**", "test-*"],
    };
  },
});
```

Changes:
- Add FindDownWithExcludes() with glob pattern support in internal/fs
- Add Exclude field to App struct
- Thread exclude patterns through type generation pipeline
- Maintain backward compatibility (node_modules and dotfiles still excluded)
- Add comprehensive test suite with 8 test cases

Fixes issues with:
- Git submodules generating unwanted sst-env.d.ts files
- Large monorepos with nested dependencies
- Test fixtures containing duplicate package.json files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant