rslib-modern-package

name

rslib-modern-package

description

Opinionated Rslib recommendations for modern JS/TS npm package design covering pure ESM, strict TypeScript, explicit exports, small stable APIs, pragmatic dependencies, accurate sideEffects, correct declarations, package validation, provenance, README.md, and AGENTS.md. Use when I want to make a JS/TS package more modern, check whether the current package setup is healthy, review package.json/exports/types/dependencies/docs/release readiness, or apply a modern library baseline.

Rslib Modern Package

Use this skill when creating a new Rslib library, modernizing an existing JS/TS package, or reviewing a package against an opinionated modern library standard.

This skill is opinionated: it describes a recommended modern package contract and may suggest breaking changes when they make the package simpler, safer, and easier for modern consumers.

Standard

Default recommendation for new JS/TS libraries:

• ESM-first, preferably pure ESM.
• Strict TypeScript and correct declaration files.
• Explicit public API through package.json#exports.
• Small named-export API surface.
• Few runtime dependencies, without treating zero dependencies as a religion.
• Small, tree-shakeable output with accurate sideEffects.
• Clear dependency placement: runtime dependencies, peer dependencies, optional dependencies, and dev dependencies are not interchangeable.
• Published package is tested as an artifact, not just as source files.
• Release flow is automated, traceable, and SemVer-aware.
• README.md explains usage for humans; AGENTS.md preserves package invariants for future agents.

Workflow

1. Inspect the package contract first

   • Read package.json, lockfile/package manager, rslib.config.*, tsconfig*, CI/release config, README.md, AGENTS.md, and existing dist output.
   • Identify package kind: Node utility, browser library, isomorphic utility, CLI, UI/component library, framework plugin, SDK, or adapter.
   • List supported runtimes, current entry points, deep imports, runtime dependencies, peer dependencies, optional integrations, files with side effects, and published files.
   • Run npm pack --dry-run early when changing package shape so the real tarball contents guide the review.

2. Define target environments explicitly

   • Do not say "supports modern environments" without defining them.
   • Verify the current Node.js release schedule before choosing engines.
   • As of May 9, 2026, Node.js 22 and 24 are LTS, and Node.js 20 is EOL. For new Node-facing packages, recommend engines.node >=22 unless real consumers need an older runtime.
   • Browser packages should state whether they require native ESM, a bundler, Workers support, SSR compatibility, DOM APIs, CSS processing, or specific browser baselines.
   • Compatibility drops are breaking changes: old Node/browser versions, undocumented deep imports, default/named export shape, bundled vs external dependency behavior, and import side effects.

3. Prefer pure ESM, but explain compatibility cost

   • New packages should use "type": "module" and ESM source/output.
   • Rslib's default format is ESM; keep that default unless there is a clear reason to add another format.
   • Evaluate compatibility from real consumers and supported runtimes instead of assuming every historical module format is required.
   • Modern Node.js can load synchronous ESM from CommonJS via require(esm); do not assume CJS consumers always require a separate CJS build.
   • If you rely on require(esm) compatibility, document and test its constraints: supported Node versions, no top-level await in the loaded graph, namespace-object return shape, default export behavior, and CJS/ESM cycle limits.
   • Prefer Node built-in specifiers such as node:fs/promises.

4. Make exports the public API

   • Treat package.json#exports as the product contract.
   • Export only paths users are meant to import.
   • Do not allow imports like pkg/dist/foo.js by exporting ./dist/*. That makes the generated output layout part of the public API and turns internal file moves into breaking changes.
   • Instead, expose only intentional public paths such as pkg and pkg/foo.js, mapped to the actual files in dist.
   • Keep subpath style consistent: either all with extensions such as ./foo.js, or all without extensions. Prefer paths with extensions when browser import maps matter.
   • Keep "types" first inside conditional exports.
   • Adding exports to an older package can be breaking because undeclared deep imports stop working.
   • Add ./package.json only when consumers legitimately need package metadata.

5. Design a small API surface

   • Prefer named exports for multi-API packages.
   • Avoid default-export objects that gather every function into one object.
   • Public functions should be few, stable, well-named, and semver-maintained.
   • Keep internal types, caches, helper functions, adapter details, and error internals private unless they are part of the contract.
   • Avoid top-level work during import: file scans, network calls, timers, process mutation, global registration, DOM access, prototype mutation, or environment detection with side effects.
   • Async APIs that may be canceled should accept AbortSignal.
   • Prefer stable error classes, error codes, or typed error shapes over string matching.

6. Use Rslib as the implementation path, not the whole standard

   • For detailed Rslib configuration guidance, use the rslib-best-practices skill.
   • In this skill, only check whether Rslib output, declarations, package.json#exports, files, dependencies, and docs agree with the modern package contract.
   • Keep Rslib configuration small and intentional; avoid adding build complexity that does not improve the package contract.

7. Keep dependencies small and intentional

   • Start from platform APIs, not from dependency search.
   • Prefer built-ins when the runtime supports them: URL, URLSearchParams, Intl, fetch, AbortController, structuredClone, crypto.randomUUID, Web Streams, TextEncoder, TextDecoder, node:fs/promises, and node:crypto.
   • Small runtime dependencies are fine when they reduce maintenance risk or implementation complexity.
   • Avoid large utility packages for one or two helpers.
   • Evaluate dependencies for ESM support, exports, types, transitive dependency count, package size, license, maintenance activity, security history, install scripts, side effects, native install fragility, and granular imports.
   • Put required runtime packages in dependencies.
   • Put host-owned frameworks and toolchains in peerDependencies, such as React, Vue, Svelte, Rspack, Rsbuild, webpack, TypeScript, and framework runtimes.
   • Keep peer ranges reasonably broad; do not pin peers to a patch version unless required.
   • Put build tools, test tools, type tools, docs tools, and Rsbuild/Rspack plugins in devDependencies.
   • Use optionalDependencies or optional peers via peerDependenciesMeta for optional integrations.

8. Make TypeScript strict and package-oriented

   • Prefer TypeScript source for TS libraries; otherwise use high-quality JSDoc plus generated declarations.
   • With TypeScript 6 or tsgo-era defaults, strict checking may already be enabled; preserve that default and do not turn it off. For older TypeScript versions or inherited configs, set strict: true explicitly.
   • In Rslib projects, consider enabling lib.dts.tsgo to speed up declaration generation when the project can use tsgo.
   • Keep module and moduleResolution aligned with how declarations are emitted and how consumers resolve the package; NodeNext and bundler-style resolution are both valid in the right toolchain.
   • Use verbatimModuleSyntax so type-only imports/exports are explicit.
   • Use isolatedDeclarations when practical so exported APIs are explicit enough for declaration-oriented tooling.
   • Emit declarations; use declaration maps when editor navigation matters.
   • Use import type and export type for type-only dependencies.
   • Do not rely on consumers setting skipLibCheck to hide broken package types.
   • Test declarations as consumers see them, especially when using subpath exports.

9. Keep sideEffects accurate

   • Use sideEffects: false only when importing package files has no top-level side effects.
   • If CSS, polyfills, registrations, global listeners, prototype changes, or other import-time mutations exist, list the files with side effects instead.
   • Do not set sideEffects: false just to improve bundle size; incorrect values can remove required CSS or setup code.
   • Do not change globals just because a file is imported. If setup is required, expose an explicit setup() or install() function and let users call it themselves.

10. Make package.json authoritative

    • Required modern shape: "type": "module", explicit exports, correct declarations, files allowlist, accurate sideEffects, sensible engines, and release scripts.
    • Include README.md, AGENTS.md, and LICENSE in files when they exist.
    • files should prevent tests, fixtures, private docs, build caches, local configs, and large generated artifacts from leaking into the tarball.
    • Avoid stale main/module fields unless compatibility evidence requires them; if kept, they must agree with exports.
    • Keep runtime dependency fields accurate. A package that works locally only because a runtime dependency is in devDependencies is broken.

11. Validate the published artifact

    • Run normal lint, typecheck, tests, and rslib build.
    • Smoke test built ESM output.
    • Run type-level tests when the public API is type-heavy.
    • Run npm pack --dry-run and inspect included files.
    • In Rslib, prefer rsbuild-plugin-publint to run publint after build; use npx publint as a CLI fallback.
    • In Rslib, prefer rsbuild-plugin-arethetypeswrong to run Are The Types Wrong after build when declarations are shipped; use npx --yes @arethetypeswrong/cli --pack . as a CLI fallback.
    • Install the packed tarball into clean consumer fixtures for important packages.
    • Test ESM import, bundler import for browser/component libraries, CLI execution for bin packages, and every public subpath export.

12. Prepare README.md and AGENTS.md before publishing

    • Always check whether both files exist before publishing or modernizing a package.
    • If either file is missing, recommend adding it; for implementation tasks, create a concise version unless I ask not to.
    • README.md should include: package name, one-sentence purpose, install/usage, key features or API links, supported environments, docs/related links, changelog or contribution link, and license.
    • AGENTS.md should include: stack, package contract, common commands, source layout, code style, validation commands, and release checklist.
    • Keep both files synchronized with package.json#exports, supported runtimes, and actual Rslib output.

13. Publish with supply-chain hygiene

    • Follow SemVer and document breaking changes.
    • Maintain a changelog for user-visible changes.
    • Use prerelease versions and dist-tags for beta/next channels.
    • Prefer CI publishing with npm provenance or trusted publishing.
    • Avoid long-lived publish tokens where trusted publishing is available.
    • Remember that a published package name/version pair cannot be reused safely.

Review Red Flags

• exports is missing, points to files not emitted by Rslib, or allows public imports such as pkg/dist/foo.js.
• module/main fields disagree with exports.
• Type declarations do not match runtime entry points.
• Runtime dependency is accidentally listed only in devDependencies.
• React/Vue/Svelte/Rspack/Rsbuild/webpack/TypeScript is bundled or placed in dependencies when it should be a peer.
• sideEffects: false is set while importing CSS, polyfills, global registrations, global listeners, or prototype changes.
• Package has install scripts without a strong reason.
• Top-level import reads user files, starts timers, touches the network, mutates globals, or assumes window/process.
• Published tarball contains private source maps, tests/fixtures that are not useful to consumers, large generated docs, local config secrets, or build caches.

Checklist

• Supported environments are explicit.
• Package is ESM-first, preferably pure ESM.
• package.json has "type": "module".
• Public entry points are declared in exports.
• No accidental reliance on undeclared deep imports.
• Rslib output, declarations, exports, and files agree.
• TypeScript strict mode is enabled.
• Declarations are emitted and validated.
• Runtime dependencies are justified and small.
• Host frameworks/toolchains are peers.
• Build/test/type/docs tools are dev dependencies.
• sideEffects is accurate.
• npm pack --dry-run has been inspected.
• publint passes.
• Are The Types Wrong check passes when declarations are shipped.
• Built ESM smoke test passes.
• README.md exists.
• AGENTS.md exists.
• Release flow uses SemVer, changelog, and provenance/trusted publishing when available.

Documentation

• For the latest Rslib docs, read https://rslib.rs/llms.txt
• Shipping ESM for CommonJS consumers: https://nodejs.github.io/package-examples/04-cjs-esm-interop/shipping-esm-for-cjs/