unjs / destr Goto Github PK

Describe the feature

If the string is longer than nine characters it cannot possibly match any of the hard-coded strings. So wrap the lowercasing operation in a conditional that prevents the operation if the string is ten characters or longer.

Additional information

• Would you be willing to help implement this feature?

Describe the feature

Many of our json data sources come from the backend, and there is an obvious need to convert the long type numbers from the backend into strings for reception (otherwise the precision will be lost), this is json-big (or other Some packages) do, it would be great if this could be supported as a built-in configuration item!

Anyway, json+ts is really nice!

Additional information

• Would you be willing to help implement this feature?

TL;DR: After updating "a" laravel package our app broke because destr evaluates all responses as string.

We are using lates laravel as backend with a fairly new plain vue3 frontend.

We are using ofetch (former ohmyfetch) for fetching api responses.
After a update laravel resources responses now have a leading whitespace, thats the reason destr evaluates the response as a string.

How to reproduce:

destr('{}') // type object
destr(' {}') // type text

Is is possible to trim the data before try parsing it?

Environment

"node": ">=16",
"pnpm": ">=8.4.0"

Reproduction

Please use a browser with a version below iOS 14.4 to access.
https://stackblitz.com/edit/typescript-hlusqb?file=index.ts

The results displayed by the Chrome browser on iOS 14.4.

Describe the bug

This is just a compatibility issue. When in iOS 14, an error occurs due to the incompatibility of the browser caused by the use of the "at" method. I'm not sure whether to fix it in this library, compile this library in my project, or provide a polyfill.

System Infomation

Additional context

We use Nuxt (v3.8.2) to develop the application. It is possible that the use of renderJsonPayloads: true in the experimental features causes the data to be parsed with destr. In most cases, this is not a problem, but someone reported a white screen issue on iOS 14.

Logs

No response

There are some properties such as in nuxt content hooks that have this syntax and cannot be parsed.

'content:file:beforeParse'

will this be supported or is it not destr's responsibility?

Hello, @pi0.

I found a memory leak, that affects Nuxt 3 framework, because the destr package is used as default parseResponse option in the ohmyfetch, that used in the Nuxt 3 useFetch() function as $fetch.

Memory leak

Flamegraph

Table

Memory usage

Temporary fix for Nuxt 3

1. Create a local TypeScript file (lib/use-fetch.ts) with copy of useFetch() function.

2. Add custom parseResponse() function:

   import type { FetchOptions } from 'ohmyfetch';
   
   /**
    * Parse response
    * @description Replace of `destr()` function to prevent memory leak
    * @param responseText
    */
   const parseResponse: FetchOptions['parseResponse'] = (responseText) => {
     // Send empty string if zero length
     if (responseText.length === 0) {
       return '';
     }
   
     try {
       return JSON.parse(responseText);
     } catch (_e) {
       return responseText;
     }
   };

3. Replace _fetchOptions constant in the copy of useFetch() function:

     const _fetchOptions = {
       ...opts,
       parseResponse,
       cache: typeof opts.cache === 'boolean' ? undefined : opts.cache
     }

4. Use patched useFetch() function instead of build-in.

Because, right now there is no way to provide custom parseResponse() function as option of the useFetch() without error.

Best wishes,
Sergey.

Environment

destr: 2.0.1(latest)
nodejs: 18.18.1

Reproduction

const value = Math.random().toString() // => '0.5207845927625354'
destr(value) // => '0.5207845927625354' ❌ should be number
JSON.parse(value) // => 0.5207845927625354 🟢 correct

Describe the bug

Parsing a string of numbers with more than 14 decimals gives incorrect results, it should return the number but actually returns the original string.

This should have something to do with the regex here：

Additional context

No response

Logs

No response

Environment

destr 2.0.1
Node.js 18

Reproduction

JSON.parse('"a\\nb"') == destr('"a\\nb"')

should be true

Describe the bug

At this line, destr returns string just stripped double quote.

Additional context

No response

Logs

No response

Environment

none

Reproduction

See issues below

Describe the bug

Right now, every constructor key will be removed. Instead, only { "constructor": { "prototype": "<...>" } } should be removed.

See https://github.com/fastify/secure-json-parse/blob/master/test/index.test.js#L228-L231

Additional context

unjs/ofetch#180

Logs

No response

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update pnpm to v8.15.6

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Describe the feature

"A faster, secure and convenient alternative for JSON.parse.".

It will be interesting versus other JsonParser ...
I dont want to search all tool (maybe twenty) who suggests the same thing (and the latest lol) ...

I have no interest by this package because already 20 or more package do the "same" things and i dont know wich is the best :o .... and why this package is so special ?

Additional information

• Would you be willing to help implement this feature?

Describe the feature

Was searching all over unjs repo and Google to find the JSON.stringify equivalent of destr and didn't find anything.

If there's one please provide the name, otherwise take it as a feature request. :)

High appreciation to the unjs ecosystem. 🔥💚👏

Additional information

• Would you be willing to help implement this feature?

Describe the feature

Hey! Based on nuxt/nuxt#15736, we could give out warnings in dev mode when keys are dropped (constructor/__proto__).

Would that make sense?

Additional information

• Would you be willing to help implement this feature?