Skip to content

Commit cc44d97

Browse files
ScriptedAlchemyScriptedAlchemy
authored
fix: prevent duplicate error prefix in Module Federation Runtime errors (#3926) (#3931)
1 parent 3748d87 commit cc44d97

File tree

4 files changed

+439
-2
lines changed

4 files changed

+439
-2
lines changed

‎.changeset/prevent-duplicate-error-prefix.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
"@module-federation/runtime-core": patch
3+
---
4+
5+
fix: prevent duplicate error prefix in Module Federation Runtime errors
6+
7+
This change fixes an issue where the `[ Federation Runtime ]` prefix was being added multiple times to error messages when errors were re-thrown or already contained the prefix. The fix includes:
8+
9+
- Check if error message already starts with the log category prefix before adding it
10+
- Properly handle Error objects to avoid mutating original errors in warn function
11+
- Add comprehensive tests to ensure prefix duplication is prevented

‎CLAUDE.md

Lines changed: 256 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,256 @@
1+
# Claude Task Parallelization Guidelines
2+
3+
## Core Principles
4+
5+
### Maximum Parallelization Strategy
6+
- **ALWAYS PARALLELIZE**: Break down ANY task into multiple parallel sub-tasks
7+
- **IMMEDIATE EXECUTION**: Launch parallel Task agents immediately without asking questions
8+
- **NO CLARIFICATION**: Skip asking about implementation details unless absolutely critical
9+
- **CONTEXT EFFICIENCY**: Each task handles only its specific scope to minimize token usage
10+
11+
## Universal Parallel Task Patterns
12+
13+
### For Any Codebase Task
14+
Analyze the request and immediately split into parallel tasks based on:
15+
16+
1. **File Type Separation**
17+
- Source code files
18+
- Test files
19+
- Configuration files
20+
- Documentation files
21+
- Build/deployment files
22+
23+
2. **Functional Separation**
24+
- Core implementation
25+
- Helper/utility functions
26+
- Integration points
27+
- Data models/schemas
28+
- External interfaces
29+
30+
3. **Directory-Based Separation**
31+
- Different modules/packages
32+
- Frontend vs backend
33+
- Library vs application code
34+
- Public vs private APIs
35+
36+
### Dynamic Task Allocation Examples
37+
38+
#### Example 1: Feature Implementation (5-7 parallel tasks)
39+
- Task 1: Core feature logic
40+
- Task 2: Supporting utilities/helpers
41+
- Task 3: Tests (if applicable)
42+
- Task 4: Integration with existing code
43+
- Task 5: Configuration updates
44+
- Task 6: Type definitions (if typed language)
45+
- Task 7: Remaining changes and coordination
46+
47+
#### Example 2: Bug Investigation (3-5 parallel tasks)
48+
- Task 1: Search for error patterns in logs/code
49+
- Task 2: Analyze related test files
50+
- Task 3: Check recent commits/changes
51+
- Task 4: Investigate similar issues in codebase
52+
- Task 5: Review documentation/comments
53+
54+
#### Example 3: Refactoring (4-6 parallel tasks)
55+
- Task 1: Identify all usage locations
56+
- Task 2: Plan new structure
57+
- Task 3: Update core implementations
58+
- Task 4: Update dependent code
59+
- Task 5: Update tests
60+
- Task 6: Verify no breaking changes
61+
62+
#### Example 4: Codebase Analysis (5-8 parallel tasks)
63+
- Task 1: Analyze file structure
64+
- Task 2: Review core business logic
65+
- Task 3: Map dependencies
66+
- Task 4: Identify patterns/conventions
67+
- Task 5: Review configuration
68+
- Task 6: Analyze build system
69+
- Task 7: Check documentation
70+
- Task 8: Security/performance patterns
71+
72+
### Adaptive Parallelization Rules
73+
1. **Minimum 3 tasks**: Even simple requests should use at least 3 parallel tasks
74+
2. **Maximum 10 tasks**: Avoid over-fragmentation; combine related work
75+
3. **File count based**:
76+
- 1-5 files: 3-4 tasks
77+
- 6-20 files: 5-7 tasks
78+
- 20+ files: 7-10 tasks
79+
4. **Complexity based**:
80+
- Simple changes: 3-4 tasks
81+
- Medium complexity: 5-7 tasks
82+
- High complexity: 7-10 tasks
83+
84+
### Post-Execution Coordination
85+
Always include a final review task that:
86+
- Synthesizes findings from all parallel tasks
87+
- Resolves any conflicts or overlaps
88+
- Runs verification commands (lint, test, build)
89+
- Provides unified summary of changes
90+
91+
## Context Optimization Strategies
92+
93+
### Code Reading Rules
94+
- **STRIP COMMENTS**: Remove all comments when analyzing existing code
95+
- **FOCUSED SCOPE**: Each task reads ONLY files relevant to its specific responsibility
96+
- **MINIMIZE CONTEXT**: Avoid loading unnecessary files to preserve token efficiency
97+
98+
### File Management
99+
- **PREFER MODIFICATION**: Always edit existing files over creating new ones
100+
- **MINIMAL CHANGES**: Make the smallest possible changes to achieve functionality
101+
- **PRESERVE PATTERNS**: Maintain existing code style and architectural patterns
102+
103+
## Implementation Guidelines
104+
105+
### Critical Rules
106+
1. **PRESERVE ARCHITECTURE**: Never change existing patterns without explicit request
107+
2. **FOLLOW CONVENTIONS**: Match existing naming, file organization, and code style
108+
3. **REUSE COMPONENTS**: Use existing utilities, hooks, and components before creating new ones
109+
4. **ATOMIC CHANGES**: Each task makes self-contained, non-conflicting modifications
110+
111+
### Efficiency Practices
112+
- Launch all tasks in a single message using multiple tool invocations
113+
- Each task should have clear, non-overlapping responsibilities
114+
- Consolidate small related changes into Task 7 to prevent over-fragmentation
115+
116+
### Error Handling
117+
- Each task should handle its own errors gracefully
118+
- If a task encounters blockers, it should document them clearly
119+
- The review task should identify and resolve integration issues
120+
121+
## Parallelization Examples
122+
123+
### Example: "Fix the login bug"
124+
```
125+
Claude: [Launches 5 parallel tasks immediately]
126+
- Task 1: Search for login-related code and error patterns
127+
- Task 2: Check recent commits touching authentication
128+
- Task 3: Analyze login tests and error logs
129+
- Task 4: Review auth configuration and dependencies
130+
- Task 5: Investigate similar issues and edge cases
131+
```
132+
133+
### Example: "Add a new API endpoint"
134+
```
135+
Claude: [Launches 6 parallel tasks immediately]
136+
- Task 1: Create endpoint handler/controller
137+
- Task 2: Add data models/validation
138+
- Task 3: Write tests for the endpoint
139+
- Task 4: Update routing configuration
140+
- Task 5: Add necessary middleware/auth
141+
- Task 6: Update API documentation
142+
```
143+
144+
### Example: "Analyze this Python codebase"
145+
```
146+
Claude: [Launches 7 parallel tasks immediately]
147+
- Task 1: Map project structure and entry points
148+
- Task 2: Analyze core business logic modules
149+
- Task 3: Review data models and database schema
150+
- Task 4: Check dependencies and requirements
151+
- Task 5: Analyze test coverage and patterns
152+
- Task 6: Review configuration and deployment
153+
- Task 7: Identify coding standards and patterns
154+
```
155+
156+
### Example: "Optimize database queries"
157+
```
158+
Claude: [Launches 5 parallel tasks immediately]
159+
- Task 1: Find all database query locations
160+
- Task 2: Analyze query performance patterns
161+
- Task 3: Review indexes and schema design
162+
- Task 4: Check for N+1 and inefficient queries
163+
- Task 5: Research caching opportunities
164+
```
165+
166+
### Task Independence Principle
167+
- Each task must be completely independent
168+
- No task should wait for another's output
169+
- All tasks read original state of codebase
170+
- Coordination happens only in final review task
171+
172+
## Best Practices
173+
174+
### Do's
175+
- ✓ ALWAYS use multiple parallel tasks (minimum 3)
176+
- ✓ Launch all tasks in a single message immediately
177+
- ✓ Break down even simple tasks into parallel subtasks
178+
- ✓ Keep each task focused on specific scope/files
179+
- ✓ Use more tasks for complex or multi-file operations
180+
- ✓ Include a coordination/review task at the end
181+
- ✓ Adapt task count based on request complexity
182+
183+
### Don'ts
184+
- ✗ Use a single task when multiple would be faster
185+
- ✗ Ask for clarification before launching tasks
186+
- ✗ Make tasks dependent on each other
187+
- ✗ Load entire codebase into a single task
188+
- ✗ Create documentation unless specifically requested
189+
- ✗ Limit parallelization to specific languages/frameworks
190+
191+
## Performance Optimization
192+
193+
### Context Management
194+
- Each task loads minimal necessary files
195+
- Strip comments when analyzing code
196+
- Focus on specific patterns/directories per task
197+
- Avoid redundant file reads across tasks
198+
- Use glob patterns to efficiently find relevant files
199+
200+
### Parallel Execution Benefits
201+
- 3-10x faster execution through parallelization
202+
- Reduced total token usage via distributed context
203+
- Better coverage through specialized tasks
204+
- Easier debugging through isolated task outputs
205+
- More thorough analysis via diverse perspectives
206+
207+
## Key Parallelization Triggers
208+
209+
### Always Parallelize When:
210+
1. **Multiple files involved** - Different tasks for different files/directories
211+
2. **Multiple aspects** - Separate tasks for logic, tests, config, docs
212+
3. **Investigation needed** - Parallel search strategies
213+
4. **Complex changes** - Break into logical subtasks
214+
5. **Analysis requested** - Different angles of analysis
215+
6. **Performance issues** - Parallel investigation paths
216+
7. **Refactoring** - Separate tasks for finding and updating
217+
218+
### Parallelization Mindset
219+
- Think "How can I split this?" not "Should I split this?"
220+
- Default to MORE tasks rather than fewer
221+
- Every request deserves parallel execution
222+
- Speed and thoroughness come from parallelization
223+
- Independent tasks = maximum efficiency
224+
225+
## Tool Preferences
226+
227+
### Package Manager
228+
- **ALWAYS use pnpm**: Never use npm, always use pnpm for all package operations
229+
- Commands: `pnpm install`, `pnpm add`, `pnpm run`, etc.
230+
- If pnpm is not available, inform the user to install it
231+
232+
### Code Search Optimization
233+
- **Prefer ast-grep**: Use `mcp__ast-grep__ast_grep_search` for structural code searches
234+
- ast-grep is superior for finding code patterns, function definitions, and structural elements
235+
- Use ast-grep when searching for:
236+
- Function/class definitions
237+
- Specific code patterns
238+
- Variable usage across files
239+
- Structural code elements
240+
- Refactoring targets
241+
- Fall back to Grep only for simple text searches or when ast-grep isn't suitable
242+
243+
### Example ast-grep Usage
244+
```
245+
# Instead of using Grep for finding function definitions:
246+
# Bad: Grep for "function getUserData"
247+
# Good: ast-grep search for function definition pattern
248+
249+
# Finding all React components:
250+
pattern: "const $COMPONENT = () => { $$$ }"
251+
252+
# Finding specific function calls:
253+
pattern: "getUserData($$$)"
254+
```
255+
256+
This system ensures Claude always leverages parallel task execution, modern tools, and efficient search methods for maximum speed and efficiency across any codebase or request type.

0 commit comments

Comments
 (0)