feat: replace uuid with prefixed string with schemaIdCounter

[Uzlopak]

We dont need crypto randomUUID, because we are cool. We use an internal counter and a fsj specific prefic to generate the schema.id.

@Ethan-Arrowood
@inlet

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

[Uzlopak]

yeah, we dont need cryptographical secure random number generation. We are just using the uuid for internal ids of the merged schemas etc..

[jsumners]

I would be extremely wary of this. Maybe schema ids are not super secretive, but the are meant to be globally unique and my uninformed guess is that Math.random is too predictable.

[Uzlopak]

For our use case it should be good enough.

[Uzlopak]

I dont know why github bot resolved this conversiation. I think @jsumners thought is important but still I think it is neglectable.

[Eomm]

Just to try out to solve this silly code:
performance.now() works on node and browses

[climba03003]

Just curious, crypto.randomUUID is using pre-allocated cache.
Is it common to have that large (128 times) of id generate which exceed the cache entropy?

[Uzlopak]

I guess it is for faster uuid generation. Like randomInt.

[mcollina]

If you need a unique identifier for just one process, you can use a global progressive integer.

[Uzlopak]

I personally think that collision wise it is easier to use this uuid implementation, because an incrementing number could result in collisions if multiple compiled json stringify are concentrated in one function.

I think this is the cheapest solution, while also keeping it somewhat unique. I dont think that collisions are possible.

[mcollina]

because an incrementing number could result in collisions if multiple compiled json stringify are concentrated in one function.

How? We don't support combining functions.

[Uzlopak]

I am worried that using just an incrementing number could result in some unexpected behavior in some dependent projects. Do we call then the internal schemas __fjs_${schemaId}

[ivan-tymoshenko]

Adding an incremental counter + internal prefix name should work.

[Uzlopak]

@mcollina
@ivan-tymoshenko

Implemented accordingly.

[mcollina]

lgtm