Skip to content

Generated types from filesystem-routing unassignable to RouteDefinition with TS exactOptionalPropertyTypes #598

Description

@eyelidlessness

Describe the bug

When TypeScript is configured with exactOptionalPropertyTypes: true, types generated by filesystem-routing are not assignable to the RouteDefinition type expected by @solidjs/router.

Your Example Website or App

Happy to put together minimal repro if necessary, it's really just basic project setup + one tsconfig setting

Steps to Reproduce the Bug or Issue

  1. Set up basic project with latest Solid 2 RC, @solidjs/router, and filesystem-routing, and generated types (types: string | true).
  2. In tsconfig.json, set "exactOptionalPropertyTypes": true
  3. TS error is reproducible with config as simple as:
import { pageRoutes } from 'virtual:file-routes';
import { createRouter } from '@solidjs/router';
import { fileRoutes } from '@solidjs/router/fs';

export const Router = createRouter({
  routes: fileRoutes(pageRoutes),
  // ^ Error here
});

Expected behavior

Types generated by filesystem-routing should be assignable to the types expected by @solidjs/router.

Observed behavior: TypeScript errors due to optional properties assigned undefined values that are not explicitly allowed by RouteDefinition optional properties.

Screenshots or Videos

No response

Platform

  • OS: macOS (but don't think it matters)
  • Browser: N/A
  • Version: N/A

I've confirmed this affects these versions (latest at time of writing):

  • @solidjs/router: 2.0.0-next.21
  • filesystem-routing: 0.3.0
Other Solid packages, in case it matters
  • @solidjs/meta: 1.0.0-next.2
  • @solidjs/vite-plugin: 3.0.0-next.38
  • @solidjs/web: 2.0.0-rc.6
  • solid-js: 2.0.0-rc.6

Additional context

Potential fix:

I've validated a trivial fix locally: in RouteDefinition, adding | undefined to each optional property1. I'd be happy to contribute this change but I don't know:

  • If it's the ideal place to address the issue (seems likely)
  • Potential for type level regressions I haven't noticed yet
  • How to test the change, or said potential regressions

I'm not sure how much appetite y'all have for adopting exactOptionalPropertyTypes internally, and fixing whatever other issues that come up. I'd be happy to look into a more thorough contribution in that vein!

Footnotes

  1. Theoretically I only needed to make this change on the children property to eliminate the type errors I see. But I also saw potential for similar conflicts on others.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions