Export PageData, PageInfo, and param types from the package entry point

[bcomnes]

Closes #227

The package exported function types (LayoutFunction, PageFunction, TemplateFunction, etc.) but not the data types those functions receive. Users writing layouts, templates, global.data.js, or page functions had no first-class way to import PageData, PageInfo, or any of the param types. The only options were reaching into internal module paths (fragile) or writing partial inline JSDoc annotations by hand.

This change adds:

• PageData as a runtime re-export from the package entry point (useful for instanceof checks as well as typing)
• PageInfo and TemplateInfo as typedef re-exports
• LayoutFunctionParams, GlobalDataFunctionParams, PageFunctionParams, and TemplateFunctionParams as typedef re-exports

All types were already defined in internal source files. This just makes them importable from @domstack/static directly.

After this change, JSDoc users can write:

/** @type {import('@domstack/static').GlobalDataFunction} */
export default function globalData ({ pages }) {
  // pages[0].pageInfo.path  -- autocompletes
}

And TypeScript users can write:

import type { PageData, PageInfo, LayoutFunctionParams } from '@domstack/static'

No breaking changes. All existing exports remain unchanged.

[Copilot]

Pull request overview

Exposes the key data/param types that user-authored layouts/templates/global data/page functions receive by re-exporting them from the @domstack/static package entry point, eliminating fragile deep-imports.

Changes:

• Re-export PageData as a runtime export from the entry point.
• Re-export PageInfo / TemplateInfo as typedefs from the entry point.
• Re-export LayoutFunctionParams, GlobalDataFunctionParams, PageFunctionParams, and TemplateFunctionParams as typedefs from the entry point.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bcomnes]

Addressed both review comments:

Comment 3105594603 (TemplateFunctionParams tuple type): Accepted. Removed TemplateFunctionParams from the public index.js exports entirely. It was a Parameters<TemplateFunction<T>> tuple, inconsistent with the object-shaped LayoutFunctionParams and PageFunctionParams. Inlined the tuple usage directly in the internal TemplateAsyncIterator definition as Parameters<TemplateFunction<T>>[0] so no external consumers are affected.

Comment 3105594609 (smoke test for public types): Noted, but deferring this to a separate PR. The project already has integration-level test fixtures in test/. Adding a standalone JSDoc/TS type fixture would be its own scoped PR. This PR stays focused on the public type surface fix.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coveralls]

Coverage Report for CI Build 24619532197

Coverage increased (+0.07%) to 91.537%

Details

• Coverage increased (+0.07%) from the base build.
• Patch coverage: 47 of 47 lines across 2 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	4108
Covered Lines:	3842
Line Coverage:	93.52%
Relevant Branches:	642
Covered Branches:	506
Branch Coverage:	78.82%
Branches in Coverage %:	Yes
Coverage Strength:	73.77 hits per line

---

💛 - Coveralls

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bcomnes]

This adds complexity to the types where I would like expect just new re-exporte. Audit this new complexity before landing.