feat: standalone mode

[climba03003]

1. move debugMode in mode option.
2. provide standalone mode which people can create the code that can directly require and run
3. fixes breaking fastify standalone error serializer build #459

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[ivan-tymoshenko]

As I understand, we need this when we want to generate stringify function for schemas that we know before runtime.

1. IMHO, it's better to create util that will use fjs to create such modules. I don't really like that one function can return a function or code of a module depending on the params.

2. Can't we create these stringify functions in the runtime? We need to do it only once. I don't think it will affect performance significantly and, more importantly, we won't have to make sure we recompile the module after we fix something in fjs.

If I missed something, please tell me.

[climba03003]

Can't we create these stringify functions in the runtime?

We always can do it.

I don't think it will affect performance significantly

I think it will affect cold start time.

[mcollina]

lgtm

[ivan-tymoshenko]

@climba03003 @mcollina I was writing a long description of why it's not the best solution. Partially my fault, I should have requested changes, probably. The question is what can we do with it now?

This solution brings a dependency on internal code structure/names. It will block a lot of optimizations that will not support function serialization.

The first thing that will not work that I found is ajv schema validation because we use uuids when inserting a schema and then we will regenerate them.

fast-json-stringify/index.js

Line 621 in 310325b

const schemaKey = i.$id || randomUUID()

[ivan-tymoshenko]

These are very serious changes, that would take a lot of effort to maintain. I guess we can fix the Fastify issue easier right now. Can we do something with it and then think deeply about what to do with this idea?

[climba03003]

I think we focus on fixing the fastify error first.
Since fastify do not use $ref in that code. We are safe from it currently.

Of course, we can provide a truely fast-json-stringify dependent free for standalone.
But, it require a bit longer time to work on.

[ivan-tymoshenko]

@climba03003 can you just rebuild error schema serializer using the last fjs version that did it correctly?

[ivan-tymoshenko]

I think we focus on fixing the fastify error first.

I agree this is a reasonable approach, but creating a new API is serious. We can't just deprecate it if we find a better solution. We will have to support it.

[climba03003]

We can't just deprecate it if we find a better solution. We will have to support it.

Yes, it is. Can we add a experimental flag to indicate the user do not use it in code at this moment or it may break somehow.
Since, we are the package maintainer for fast-json-stringify and fastify.
I think we are safe to use it first and we know the limitation of it.

[mcollina]

The original refactoring should not have shipped as they broke an important use case for Fastify. I'm happy to remove this flag in a semver-major change (if it's the only change) and update Fastify accordingly.