ESLint version

HEAD

What problem do you want to solve?

Currently, when we serialize languageOptions, and non-serializable value throws an error. For instance:

{
    languageOptions: {
        parse() {}
    }
}

We work around this for parsers by not attempting to serialize an object if we can calculate an object ID for it (due to presence of meta property). However, it's not practical add meta on any object that might be passed into languageOptions, especially if that object is deeply nested. This leaves users and language plugin authors a bit stuck if they need a function to be passed in.

What do you think is the correct solution?

We can modify the current serialization logic to also check if a value has a toJSON() method (which is the standard way to indicate a different JSON serialization behavior for any object), and if so, call toJSON() instead of trying to serialize the object.

This would allow language plugin authors to place toJSON() on any object that can't be natively serialized and would allow more functionality to be available through languageOptions.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response