DayOfWeek type no longer importable from @internationalized/date after 3.12.1

[csprle]

Provide a general summary of the issue here

DayOfWeek type ('sun' | 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat') is no longer importable from @internationalized/date as of 3.12.1, despite being used in the public signatures of startOfWeek, endOfWeek, and getDayOfWeek.

🤔 Expected Behavior?

DayOfWeek should be importable from @internationalized/date since it appears directly in the public API and consumers need it to type their own firstDayOfWeek props.

😯 Current Behavior

import { type DayOfWeek } from '@internationalized/date';
// TS error: '"@internationalized/date"' has no exported member named 'DayOfWeek'.

💁 Possible Solution

Export DayOfWeek from queries.ts and re-export it from index.ts:

// queries.ts
export type DayOfWeek = 'sun' | 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat';

// index.ts
export type { DayOfWeek } from './queries';

🔦 Context

DayOfWeek appears in the public signatures of exported functions:

startOfWeek(date: DateValue, locale: string, firstDayOfWeek?: DayOfWeek): DateValue
endOfWeek(date: DateValue, locale: string, firstDayOfWeek?: DayOfWeek): DateValue
getDayOfWeek(date: DateValue, locale: string, firstDayOfWeek?: DayOfWeek): number

Consumers who accept firstDayOfWeek as a prop and forward it to these functions need to type that prop. Without an exported DayOfWeek there is no canonical type — users must either duplicate the string union or derive it unsafely.

🖥️ Steps to Reproduce

1. Install @internationalized/date@3.12.1
2. Add import { type DayOfWeek } from '@internationalized/date' to any TypeScript file
3. TypeScript reports: Module '"@internationalized/date"' has no exported member named 'DayOfWeek'

Was working in 3.12.0.

Version

@internationalized/date: 3.12.1

[snowystinger]

Hmmm doesn't look like it was previously exported https://npmx.dev/diff/@internationalized/date/v/3.12.0...3.12.1?file=dist/types/src/index.d.ts

Typescript does have an issue, you can import types from a .d.ts file even if the they are not exported. Which many auto importing tools would just do this and never inform you that it was meant to be private.

We did move to using exports fields in package.json, so the file they are in may no longer be reachable, causing it to appear like it's suddenly change public to private.

That said, we can consider exporting it formally. Thanks for understanding that Typescript has some problems that can make it hard to predict things like this.