confgen VS json5-spec

FWIW, I have a side project, confgen https://github.com/erikpukinskis/confgen, which tries to help with this.

Assuming it’s an app (and not a library) get what you are describing you would run:

    npx confgen@latest @app vite typescript eslint prettier react

It’s still early days, but I have been working on this…

There are scaffolding tools that help configure all the JavaScript frontend stuff you need, but the problem is you run them once and you can’t ever run them again to change/add stuff.

So I built Confgen which is sort of like create-react-app except it’s idempotent:

https://github.com/erikpukinskis/confgen

It’s very alpha, but I would love to get ideas/ bug reports on GitHub.

It’s also currently Vite-only, but I’m open to a possible webpack/babel mode in the future.

I made my own for exactly the reasons you cite: https://github.com/erikpukinskis/confgen but it’s extremely opinionated and very alpha. Basically, if you are working in the cluster of Vite, TypeScript, Apollo, etc it will work but it doesn’t work with anything else.

One of the larger issues I've run into is duplicates. Douglas Crockford, JSON's inventor, tried to fix the duplicate issue but it was decided it was too late. Although Douglas Crockford couldn't change the spec forcing all implementations to error on duplicate, his Java JSON implementation errors on duplicates. Others use last-value-wins, support duplicate keys, or other non-standard behavior. The JSON RFC states that implementations should not allow duplicate keys, notes the varying behavior of existing implementations, and states that when names are not unique, "the behavior of software that receives such an object is unpredictable." Duplicate fields are a security issue, a source of bugs, and a surprising behavior to users. See the article, "An Exploration of JSON Interoperability Vulnerabilities" Disallowing duplicates conforms to the small I-JSON RFC, which is a stricter JSON. The author of I-JSON, Tim Bray, is also the author of JSON RFC 8259. See also the JSON5 duplicate issue.

Virtually any sequence is not the same as adopting a specification five years after it’s been published and adopted by industry: https://spec.json5.org/

I appreciate that SQLite can’t write the format, because those changes are human afordances

That's why you pick a superset of JSON that already has some adoption, like JSON5: https://spec.json5.org/

The "dual" standard RFC 8259 [1] (both are normative standards under their respective bodies, ECMA and IETF) is also a useful comparison here. It's wording is a bit stronger than ECMA's, though not by much. ("Good interoperability" is its specific call out.)

It's also interesting that the proposed JSON 5 (standalone) specification [2] doesn't seem to address it at all (but does add back in the other IEEE 754 numbers that ECMA 404 and RFC 8259 exclude from JSON; +/-Infinity and +/-NaN). It both maintains that its numbers are "arbitrary precision" but also requires these few IEEE 754 features, which may be even more confusing than either ECMA 404 or RFC 8259.

[1] https://datatracker.ietf.org/doc/html/rfc8259#section-6

[2] https://spec.json5.org/#numbers

For anyone coming back to this, I just wrote a small proposal to define JSON5 duplicate object name behavior. I'd love any support on the issue:

https://github.com/json5/json5-spec/issues/38