utils

Decide placement of new helper functions between @ethernauta/utils and package-local colocation.

1|Updated Jul 22, 2025
One-click install
npx skills add https://github.com/niconiahi/ethernauta --skill utils-niconiahi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: utils
Source: https://github.com/niconiahi/ethernauta/tree/main/skills/utils
Command: npx skills add https://github.com/niconiahi/ethernauta --skill utils-niconiahi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents helper-function sprawl by making it clear where new utilities belong, so your codebase stays pure, dependency-light, and reusable.

Core Features & Use Cases

  • Package-boundary rules: Enforces that @ethernauta/utils remains pure and dependency-free, with no I/O, no DOM, no wallet/chains side effects, and minimal module-scope behavior.
  • Catalog + signatures: Documents the expected functions (hex/bytes, units, time, RLP, assertions, and string case conversion) and their intended types and constraints.
  • Decision rubric for new helpers: Provides an explicit checklist to decide whether to add to @ethernauta/utils or colocate next to the caller (e.g., domain-specific logic, stateful dependencies, or single-use helpers).
  • Contribution checklist & pitfalls: Guides naming conventions, testing expectations, re-exporting, and common mistakes like adding UI-specific formatting or standard-library-hiding wrappers.

Quick Start

Use the skills/utils guidance to decide where a new helper should live, then add it to @ethernauta/utils only if it satisfies the pure, dependency-free, domain-agnostic, multi-package criteria.

Frequently Asked Questions about utils

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where to place a utility function in a TypeScript monorepo?

To place a utility function in a TypeScript monorepo, use a decision rubric checking if the helper is pure, side-effect-free, and domain-agnostic. If it meets these criteria, add it to the shared utilities package; otherwise, colocate it locally with the caller.

What are the rules for keeping shared utility packages dependency-free?

Shared utility packages must stay dependency-free by enforcing no I/O, no DOM access, no wallet or RPC side effects, and minimal module-scope behavior. This ensures utilities remain reusable and avoid dependency creep across the monorepo.

When should I colocate helper functions instead of adding them to a shared package?

Colocate helper functions instead of adding them to a shared package when the logic is domain-specific, requires stateful dependencies, is single-use, or couples to a particular domain. Shared packages should only contain pure, domain-agnostic utilities.

Can I add UI-specific formatting functions to a general utilities package?

No, you should not add UI-specific formatting functions to a general utilities package. The package must stay domain-agnostic and side-effect-free, meaning UI formatting should be colocated next to the caller rather than centralized in shared utilities.

What types of pure helper functions belong in a shared utils package?

Pure helper functions that belong in a shared utils package include hex and byte conversions, units calculations, time utilities, RLP encoding, assertions, and string case conversion. These must be side-effect-free with no external dependencies.

Why does my monorepo suffer from helper-function sprawl and dependency creep?

Monorepo helper-function sprawl and dependency creep occur when utilities are added to shared packages without enforcing purity boundaries, introducing I/O, DOM access, or domain coupling. Applying a strict catalog and decision rubric prevents this by ensuring proper colocation.