After a painful investigation, it seems that the issue lies in fast-json-stringify package.

From the package README file:

fast-json-stringify is significantly faster than JSON.stringify() for small payloads. Its performance advantage shrinks as your payload grows. It pairs well with flatstr, which triggers a V8 optimization that improves performance when eventually converting the string to a Buffer.

So, this might be the cause of the issue. I have not figured out the exact reason why it does not play nice with bytenode. Still investigating.

This is the portion that causes the error by the way:

Found it.

Here https://github.com/fastify/fast-json-stringify/blob/master/index.js#L53-L62 :

    code += `
    ${$asString.toString()}
    ${$asStringNullable.toString()}
    ${$asStringSmall.toString()}
    ${$asNumber.toString()}
    ${$asNumberNullable.toString()}
    ${$asIntegerNullable.toString()}
    ${$asNull.toString()}
    ${$asBoolean.toString()}
    ${$asBooleanNullable.toString()}

The generated code uses .toString(); function dynamically. Bytenode removes the source code alltogether, so when you call .toString() on any function all you will get is an empty string (or, to be more accurate, a series of zero-width spaces).

So, in principle you can't use bytenode to protect a code that relies on Function.prototype.toString function. Protection here means no [dynamic] access to the function's source code, which contradicts -in principle- what fast-json-stringify is trying to do.

Wow nice thanks!
Makes sense now.

I will add this to the "known limitations" in the README file soon.

Closing now.

I got the same issue, some web framework dynamically loads its components, and uses toString to judge whether a class is loaded, which requires operator new to init.

see: https://github.com/miguelmota/is-class/blob/master/is-class.js#L13

I am digging into v8 to find some workaround.