install
source · Clone the upstream repo
git clone https://github.com/Intense-Visions/harness-engineering
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/Intense-Visions/harness-engineering "$T" && mkdir -p ~/.claude/skills && cp -r "$T/agents/skills/claude-code/js-singleton-pattern" ~/.claude/skills/intense-visions-harness-engineering-js-singleton-pattern && rm -rf "$T"
manifest:
agents/skills/claude-code/js-singleton-pattern/SKILL.mdsource content
JS Singleton Pattern
Ensure a class has only one instance and provide a global access point
When to Use
- You need exactly one shared instance across the entire application (e.g., a database connection, logger, or config object)
- Multiple parts of the codebase should access the same object without prop-drilling or passing references
- The instance is expensive to create and should be reused
Instructions
- Create a class with a private constructor and a static instance variable.
- Add a static
method that returns the existing instance or creates one on first call.getInstance() - Export only
, not the class itself.getInstance() - In ESM modules, prefer a module-level variable over a class — a module is already a singleton by the loader.
// Preferred ESM approach — module-level singleton let instance; class DatabaseConnection { constructor(url) { if (instance) return instance; this.url = url; this.connected = false; instance = this; } connect() { this.connected = true; } } export const getInstance = (url) => new DatabaseConnection(url);
- Freeze the instance with
if it should be immutable after creation.Object.freeze(instance) - Avoid singletons for anything that varies per request in server-side code.
Details
The Singleton pattern is one of the most debated patterns in JavaScript. The classic implementation uses a class with a static instance, but ES modules provide a simpler alternative: any module-level variable is effectively a singleton because Node.js and browsers cache module exports after the first
import.
Trade-offs:
- Singletons introduce global state, making code harder to test (you cannot easily create a fresh instance per test)
- Hidden dependencies — callers cannot know from the function signature that they depend on a singleton
- Mutable singletons are a source of subtle bugs in concurrent environments (avoid in server-side code handling multiple requests)
When NOT to use:
- When you need multiple instances with different configurations
- In unit tests — inject dependencies instead and pass a fresh instance per test
- When the "singleton" is stateless — a plain object literal or a set of pure functions is simpler
Related patterns:
- Module Pattern — a module-scoped variable achieves singleton semantics without a class
- Proxy Pattern — a Proxy can intercept access to a singleton to add logging or validation
Source
https://patterns.dev/javascript/singleton-pattern
Process
- Read the instructions and examples in this document.
- Apply the patterns to your implementation, adapting to your specific context.
- Verify your implementation against the details and edge cases listed above.
Harness Integration
- Type: knowledge — this skill is a reference document, not a procedural workflow.
- No tools or state — consumed as context by other skills and agents.
Success Criteria
- The patterns described in this document are applied correctly in the implementation.
- Edge cases and anti-patterns listed in this document are avoided.