🐛 Bug: TypeScript Type Safety Compromised - Extensive Use of `any` Types Across Codebase

[vtushar06]

Describe the bug

The codebase has the ESLint rule @typescript-eslint/no-explicit-any disabled in .eslintrc.js (line 45), which has led to widespread usage of the any type across the project. This significantly undermines TypeScript's type safety benefits and increases the risk of runtime errors.

Currently, there are 113 occurrences of explicit any types spread across 40+ TypeScript files, including critical components like:

• Page components and their props
• Store selectors (Zustand)
• JSON Editor (Slate)
• Utility functions
• Event handlers

While TypeScript's strict mode is enabled in tsconfig.json, the disabled ESLint rule has allowed any types to proliferate, creating a contradiction in the project's type safety strategy. This makes the code harder to maintain, refactor, and can hide potential bugs that would otherwise be caught at compile time.

Steps To Reproduce

1. Open .eslintrc.js and check line 45 - the rule @typescript-eslint/no-explicit-any is set to 'off'
2. Run a search for : any across .ts and .tsx files in the codebase
3. Check key files like:
   • components/Layout.tsx (lines 35, 63, 179)
   • components/JsonEditor.tsx (lines 407, 612, 694, 786-831)
   • components/GettingStarted.tsx (lines 12, 18, 142, 197)
   • pages/index.page.tsx (lines 53, 91, 450, 469, 478, 537)
   • lib/calendarUtils.ts (line 16)
   • lib/getScopesOfParsedJsonSchema.ts (line 11)
4. Notice the lack of type safety and autocomplete in these areas

Expected Behavior

The codebase should have proper TypeScript types defined throughout, with the @typescript-eslint/no-explicit-any rule enabled (at minimum as a warning, ideally as an error). This would:

• Provide better IDE autocomplete and IntelliSense
• Catch type-related bugs at compile time rather than runtime
• Make the code more self-documenting and easier to understand
• Improve refactoring safety
• Align with TypeScript best practices and the project's strict mode configuration

Screenshots

No response

Device Information [optional]

Are you working on this issue?

Yes

Do you think this work might require an [Architectural Decision Record (ADR)]? (significant or noteworthy)

No

[vtushar06]

Hi @Utkarsh-123github @Honyii ,

I've identified a type safety issue: 113 any types across 40+ files due to the disabled ESLint rule @typescript-eslint/no-explicit-any. I'd like to fix this through multiple small PRs(grouped by category: store selectors, component props, page components, etc.) rather than one massive PR. This approach will:

• Make reviews much easier
• Allow incremental testing
• Reduce merge conflict risks

I've already categorized all occurrences into 7 fix categories (ranging from easy to complex). Each PR will be focused, well-typed, and thoroughly tested. Could you assign this to me and confirm the multi-PR approach works for you?

[Utkarsh-123github]

Hi @vtushar06 , Thanks for raising this issue. A similar issue is already present, https://github.com/json-schema-org/website/issues/1034 , Could you please work on that instead to avoid duplication? Also I would suggest to make the changes in a single or at max 2 PRs, because I don't think it requires much code changes. Thank you🙌🏻

[vtushar06]

sure @Utkarsh-123github.