feat: add package.json exports

[gavriliumircea]

This pr addresses #14.

Summary by CodeRabbit

• New Features
  • Explicit public API with improved module entry points for better TypeScript support
  • New subpath imports available: chains, contracts, and releases
  • Enhanced module resolution and tree-shaking capabilities

[gavriliumircea]

• feat: add solana test and extract evm test in separate directory #67 : 2 dependent PRs (#68 , #76 )
• feat: support for solana contracts and releases #66
• feat: add solana release versions #61
• feat: add solana chains #60
• feat: add solana idls #59
• refactor: extract evm specific data in separate directory #65
• feat: add package.json exports #58 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[PaulRBerg]

Are these PRs draft, still?

[gavriliumircea]

Are these PRs draft, still?

I want to add one more pr to this stack with support for the solana addresses and afterwards I will put all the stack in Ready to Review

[coderabbitai]

Walkthrough

The pull request adds an exports field to package.json, defining explicit module entry points and TypeScript type definitions for the package root and subpaths (chains, contracts, releases), along with re-exports for metadata files and the dist directory.

Changes

Cohort / File(s)	Summary
Package Export Configuration package.json	Added exports field with module mappings for package root and subpaths (./chains, ./contracts, ./releases), each specifying TypeScript type definitions and JavaScript entry points, plus re-exports for ./package.json and ./dist/*

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 Exports declared, the paths run clear,
Root and subpaths now appear—
Chains, contracts, releases arranged with care,
A public API, honestly laid bare! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "feat: add package.json exports" directly and accurately describes the main change in the changeset. The PR adds an exports field to package.json with explicit module-like public API surface and type definitions, mapping the package root and specific subpaths (chains, contracts, releases) to their corresponding entry points. The title is specific, clear, and concise—a teammate reviewing the commit history would immediately understand that this PR introduces package export mappings without needing to inspect the actual changes.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 10-20-feat_add_package.json_exports

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

package.json (1)

5-6: Minor: Path format inconsistency between main/types and exports root.

The root main field (line 5) uses dist/index.js without a leading dot, while the exports root (line 46-47) uses ./dist/index.js with a leading dot. The subpath exports (lines 50, 54, 58) consistently use the ./dist/ prefix. Consider normalizing to use ./dist/ throughout for consistency.

-  "main": "dist/index.js",
+  "main": "./dist/index.js",

Also applies to: 45-48

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 111843d and d5eb391.

📒 Files selected for processing (1)

• package.json (1 hunks)

🔇 Additional comments (1)

package.json (1)

44-63: All exported subpaths are correctly configured and will be built successfully.

Verification complete: The source structure confirms all four subpaths (chains, contracts, releases, and root index) exist in src/ and will be compiled to dist/ by the build system. The justfile's tsc-build recipe outputs to the dist/ directory with TypeScript declaration files, so all export paths in package.json are valid.

The wildcard export ./dist/* remains permissive but is a deliberate design choice for this SDK. If narrower control over the public API surface is preferred, you could replace it with explicit subpaths only. Otherwise, the exports configuration is sound.

[razgraf]

Saw this recently re. automating exports: https://x.com/_jxom/status/1981104535537144076

List is small now, easy to maintain, but a cool tool in case it grows over time.