본문으로 건너뛰기
cccskills
무료GitHub에 공개

typescript-compile-check-resilient

Run TypeScript type checks when standard commands fail, then filter diagnostics to files involved in your task. Preserve the compiler’s exit status while reviewing relevant errors separately from existing project errors.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

TypeScript compile-checking in projects where npx and node_modules/.bin symlinks fail, with a filtering technique to isolate errors from only newly-created or task-specific files — ignoring pre-existing legacy errors.

설치 방법 보기

이럴 때 유용합니다

  • Running type checks when npx tsc fails
  • Reviewing diagnostics for newly created files
  • Filtering errors to a feature directory
  • Capturing compiler exit status in CI

포함된 파일(2)

  • SKILL.md4.7 KB
  • .skill_id48 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

TypeScript Compile-Check (Resilient) with File-Scoped Error Filtering

Use this workflow when you need to validate TypeScript changes in a project but the standard npx tsc or node_modules/.bin/tsc invocations fail due to broken symlinks, missing PATH entries, or environment issues.


When to Use This Skill

  • npx tsc fails with "command not found" or permission errors
  • node_modules/.bin/tsc symlink is broken or unresolvable
  • You need to validate only newly-created or task-specific files without being blocked by pre-existing compile errors in the broader codebase

Step 1 — Invoke tsc Directly via node_modules

Bypass npx and symlinks entirely by calling the TypeScript binary directly:

node_modules/typescript/bin/tsc --noEmit 2>&1; echo EXIT:$?

Why this works: The tsc CLI entry point is a plain Node.js script at node_modules/typescript/bin/tsc. It does not depend on symlinks or PATH resolution. The --noEmit flag checks types without writing output files. Capturing EXIT:$? lets you programmatically detect success (EXIT:0) vs failure (EXIT:1 or higher).

If the project uses a custom tsconfig, specify it explicitly:

node_modules/typescript/bin/tsc --noEmit --project tsconfig.json 2>&1; echo EXIT:$?

Step 2 — Filter Output to Task-Specific Files Only

When a legacy codebase has pre-existing errors, the full tsc output will be noisy and may cause false negatives. Pipe through grep to isolate errors from only the files you created or modified:

node_modules/typescript/bin/tsc --noEmit 2>&1 \
  | grep -E "(file-pattern)" ; echo EXIT:${PIPESTATUS[0]}

Examples

Single new file:

node_modules/typescript/bin/tsc --noEmit 2>&1 \
  | grep -E "settings-store\.ts"

Multiple new files (pipe-delimited pattern):

node_modules/typescript/bin/tsc --noEmit 2>&1 \
  | grep -E "(settings-keys|settings-store|preferences|SettingsModal)"

All files in a specific directory:

node_modules/typescript/bin/tsc --noEmit 2>&1 \
  | grep -E "src/features/my-feature/"

Check: no output = no errors in your files (success).


Step 3 — Capture Exit Code Correctly Through a Pipe

When grepping, the shell exit code reflects grep, not tsc. Use ${PIPESTATUS[0]} (bash) to recover the original tsc exit code:

node_modules/typescript/bin/tsc --noEmit 2>&1 \
  | grep -E "(my-file-pattern)"; echo "TSC_EXIT:${PIPESTATUS[0]}"

Or store errors explicitly:

TSC_OUTPUT=$(node_modules/typescript/bin/tsc --noEmit 2>&1)
TSC_EXIT=$?
echo "$TSC_OUTPUT" | grep -E "(settings-keys|settings-store|preferences|SettingsModal)"
echo "TSC_EXIT:$TSC_EXIT"

The second approach (storing output in a variable) is the most reliable since $? is captured before the pipe.


Step 4 — Interpret Results

ConditionMeaning
TSC_EXIT:0, no grep output✅ Full project clean, your files are fine
TSC_EXIT:1, no grep output✅ Your files are fine; pre-existing errors elsewhere (acceptable)
TSC_EXIT:1, grep output present❌ Your files have errors — fix them
TSC_EXIT:2❌ tsc configuration error (bad tsconfig, missing typescript package)

Fallback: Verify TypeScript Is Installed

If node_modules/typescript/bin/tsc does not exist:

# Check if typescript is installed
ls node_modules/typescript/bin/tsc 2>/dev/null || echo "TypeScript not installed"

# Install if needed
npm install --save-dev typescript
# or
yarn add --dev typescript

Full Example

# Store full tsc output and exit code
TSC_OUTPUT=$(node_modules/typescript/bin/tsc --noEmit 2>&1)
TSC_EXIT=$?

# Show only errors in newly-created files
NEW_FILE_ERRORS=$(echo "$TSC_OUTPUT" | grep -E "(settings-keys|settings-store|preferences|SettingsModal)")

if [ -z "$NEW_FILE_ERRORS" ]; then
  echo "✅ No TypeScript errors in new files (TSC_EXIT:$TSC_EXIT)"
else
  echo "❌ TypeScript errors in new files:"
  echo "$NEW_FILE_ERRORS"
  exit 1
fi

Notes

  • This technique is safe for CI and local environments alike.
  • The direct node_modules/typescript/bin/tsc path works on macOS, Linux, and Windows (via node node_modules/typescript/bin/tsc on Windows CMD).
  • On Windows, replace the bash script with: node node_modules/typescript/bin/tsc --noEmit
  • Always prefer --noEmit for validation-only checks to avoid side effects.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Prepare audio stems, the separate parts of a track, for mixing by matching their durations with silence, loops, or crossfades. Verify each generated and processed file before moving to the next production step.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Match audio parts with different durations
  • Extend drums and melodic parts using suitable methods
  • Check audio specifications before mixing
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

Produce audio in separate stems, meaning individual instrument tracks, and verify each output as you go. Align track lengths with silence, loops, or crossfades, then apply effects, mix a master, and package the files.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Align instrument tracks to a reference audio file
  • Choose how to extend tracks that are too short
  • Verify audio properties after generation and effects
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

Build serverless endpoints that relay external API requests for a dashboard while keeping API keys on the server. Includes Vercel examples for input checks, caching, cross-origin access, and consistent JSON responses.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Connect a dashboard to external APIs without exposing API keys
  • Create endpoints for stock quotes and news
  • Standardize API responses and error handling
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

Produce a master track and separate audio parts through a structured Python workflow. Apply filters and reverb, export WAV files with consistent settings, package them in a ZIP archive, and check that the deliverables meet the requested specifications.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Export a master track with separate audio parts
  • Apply filters and reverb to audio
  • Check duration and format across deliverables
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

Keep document creation moving when web searches and page retrieval repeatedly fail. The skill preserves the original task, uses the model’s existing knowledge, and clearly identifies information that could not be checked against external sources.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Continue drafting after repeated web retrieval failures
  • Preserve task requirements during network errors
  • Mark information that could not be externally verified
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

When Python execution repeatedly fails in execute_code_sandbox, use a file-based alternative: save the script, run it through the shell, and capture results or errors. The guidance covers paths, imports, timeouts, structured output, and optional cleanup.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Retry Python work through the shell after repeated sandbox failures
  • Run longer tasks with an adjusted timeout
  • Execute Python work that needs multiple files or system utilities
HKUDS/OpenSpace7.8천2026년 8월 13일 업데이트

HKUDS의 스킬 모두 보기

이 스킬의 문제 신고