Circular References on i18n default export cause JSON.stringify(i18n) to throw.

[elInfidel]

🐛 Bug Report

The i18n object has circular references causing JSON.stringify to fail. This breaks error
tracking solutions that rely on JSON.stringify to build data about exceptions that may be throwing
from i18n.

To Reproduce

import i18n from "i18next";
JSON.stringify(i18n);

Expected behavior

JSON.stringify should not throw.

Your Environment

running the following to patch this in my own project.

i18n["toJSON"] = () => `{ "i18n": "Function removed, see i18n.ts for more details." }`;

[adrai]

Why should someone want to stringify i18next?

[elInfidel]

Why should someone want to stringify i18next?

Error tracking solutions like Sentry and New Relic use stringify when encountering exceptions. I'd follow that question up by posing my own. Why expose a toJSON function on i18next.

While this is easily patched around I've seen similar issues raised against the behaviour. The existence of toJSON exposes this edge case unnecessarily I would argue. At the least, toJSON shouldn't be outputting fields that reference back.

#440

[jamuhl]

That does not reply the question. i18next is a class not a data object and therefore is not serizable. why should it be stringified if it can‘t be parsed back.

[adrai]

At most we could do something like that:

But I still don't get the use case. 🤷‍♂️

[elInfidel]

But I still don't get the use case. 🤷‍♂️

To explain my specific use case, we use Sentry in one of our applications, it is encountering an exception that includes i18n in the event data. Sentry uses JSON.stringify() to serialize the event and send it up to their server so we can process errors and squash bugs. When sentry hits i18n it throws an exception which results in the data sent to the server being about the circular dependency, not the actual error that caused Sentry to get involved in the first place.

While my situation was unfortunate, it's not that big of a deal, it can always be worked around.

That does not reply the question. i18next is a class not a data object and therefore is not serizable. why should it be stringified if it can‘t be parsed back.

Agreed, it's a class. It's not serializable and in an ideal world no one should be trying to serialize it. What purpose is toJSON actually serving on this object? I would argue that toJSON should only return fields that are serializable.

As per MDN documentation for stringify
"If the value has a toJSON() method, it's responsible to define what data will be serialized."

I mostly just wanted to raise a discussion around the value of the toJSON function here. Can anyone define a use case for toJSON that doesn't involve some sort of serialization/transmission. Is there value in adhering to the expectations of the specification for stringify in your eyes.

[adrai]

I don't know Sentry, but if it really tries to JSON.stringify everything it is a mess I can imagine...
just releasing a new i18next version v20.3.0