Proposal to merge @miichom/lodestone into @xivapi/nodestone

[miichom]

I would like to open a discussion about consolidating @miichom/lodestone into @xivapi/nodestone.

I’ve been actively updating @miichom/lodestone with Zod v4 (locally) to ensure strict end-to-end type safety against Lodestone’s HTML structure. Rather than maintaining a separate library with lower discoverability, bringing this modernised schema engine into @xivapi/nodestone combines @xivapi's ecosystem reach with guaranteed type accuracy.

Key Advantages

• End-to-End Type Safety (z.input vs z.output):
  • Query Inputs (z.input): Strongly types arguments, filters, and DOM parameters passed into queries.
  • Result Handling (z.output): Guarantees sanitised, post-transform output (coerced numbers, formatted dates, validated Enums).
• Resilient Parsing: Missing or optional properties are explicit, preventing silent runtime failures when Lodestone changes.
• Upstream Selectors & JSON Export: These Zod schemas can be moved directly into xivapi/lodestone-css-selectors. This allows generating static .json schema definitions on build, making the type contracts shareable across non-TypeScript parsers in the @xivapi ecosystem.

Basic example for /lodestone/character?q=

z.object({
  q: z.string(),
  worldname: z
    .union([
      z.enum(Region),
      z.enum(Datacenter),
      z.string().regex(/^[A-Za-z]+$/),
    ])
    .optional(),
  classjob: z.union([z.enum(Class), z.enum(Job)]).optional(),
  race_tribe: z.union([z.enum(Race), z.enum(Tribe)]).optional(),
  blog_lang: z.enum(["ja", "en", "de", "fr"]).optional(),
  page: z.number().min(1).max(20).optional(),
  ...
});

[Supamiu]

That's a good idea imo!

[miichom]

I will do some fixing up then then create a PR, for testing and showcasing I will keep the schemas internal.