feat(types): improve JSONParsed

[m-shaka]

I've improved JSONParsed in order to follow the spec of JSON.stringify as much as possible.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#description

Here is major improvement:

• support tuple type
• handle undefined, symbol, and function type correctly(in array or object). For example
  • convert undefined to null in an array
  • drop keys whose value is undefined

You can see some actual behaviour in TS playground

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.86%. Comparing base (d038d82) to head (4ec9c4a).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3074      +/-   ##
==========================================
- Coverage   95.87%   95.86%   -0.02%     
==========================================
  Files         137      137              
  Lines       13466    13492      +26     
  Branches     2381     2382       +1     
==========================================
+ Hits        12911    12934      +23     
- Misses        555      558       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yusukebe]

Hi @m-shaka

Awesome! Following the spec of JSON.stringify is great.

One thing we have to consider is performance. This change will introduce significant performance degradation, especially in RPC.

Try to create an app that has many routes with this script:

import { writeFile } from 'fs'

const count = 200

const generateRoutes = (count: number) => {
  const imports = `
import { Hono } from 'hono';
import { z } from 'zod';
import { zValidator } from '@hono/zod-validator';
`

  const schema = `
const schema = z.object({
  q: z.string()
})\n
`

  let routes = imports + schema + 'export const app = new Hono()\n'
  for (let i = 1; i <= count; i++) {
    routes += `  .get('/route${i}/:id', zValidator('query', schema), (c) => {
    return c.json({
      query: c.req.valid('query'),
      id: c.req.param('id'),
      ok: true
    })
  })\n`
  }
  return routes
}

const routes = generateRoutes(count)

writeFile('app.ts', routes, (err) => {
  if (err) throw err
  console.log(`${count} routes have been written to app.ts`)
})

Load this app in another script with hc:

import { app } from './app'
import { hc } from 'hono/client'

const client = hc<typeof app>('/')

If with current version 4.4.10, it can handle over 200 routes in my IDE:

But with this PR, it will throw the error:

Performance issues are often reported in this project, so we must address them. We want a good idea to support both the following specs and better performance. We may be able to ignore this matter and refactor other points (like hc) to ensure good performance for RPC. However, we don't want to decrease the performance as much as possible with these JSON things.

@m-shaka @NamesMT Any thoughts?

[yusukebe]

Ah, the script includes a validator, so it's better to use this script:

import { writeFile } from 'fs'

const count = 200

const generateRoutes = (count: number) => {
  let routes = `import { Hono } from 'hono'
  export const app = new Hono()`
  for (let i = 1; i <= count; i++) {
    routes += `  .get('/route${i}/:id', (c) => {
    return c.json({
      ok: true
    })
  })\n`
  }
  return routes
}

const routes = generateRoutes(count)

writeFile('app.ts', routes, (err) => {
  if (err) throw err
  console.log(`${count} routes have been written to app.ts`)
})

[m-shaka]

Oh, I'll have a look later 👀

[m-shaka]

@yusukebe While I've changed the behaviour of optional keys, it seems to work now.
Now a?: string gonna be converted to a: string | undefined, but I don't think it's a problem in practical use
{ a: string | undefined } will remain required, instead of being converted to optional like { a?: string | undefined }

[yusukebe]

@m-shaka Thanks! I'll check it later.

[yusukebe]

LGTM!

[yusukebe]

@m-shaka

Great! There is little or no performance degradation. Looks good! I wonder if we should merge this into the current main or the next branch(for the next minor release, v4.5). I'll merge later. Thanks!

[yusukebe]

Hi @m-shaka

This is a feat but does not introduce a new future for users. So, I'll merge this now into the main and include it in a patch release. Thanks!