I need your brain! Today, I started working on the Emmett CLI and Config file structures.
I want Emmett to be able to generate the schema upfront for event store and read models. I also want to make a first step towards plugin infrastructure and modularity.
Check the sample config file. It'll contain plugins (similar to eslint, etc.) so each Emmett package can self-register, and community plugins can be registered in the future.
I'm unsure about the configuration structure yet, but I'd like it to be fully typed and follow conventions. Thanks to that, I'll be able to run migrations and, in the long term:
- generate documentation,
- code like command handlers, WebApi routings,
- run diagnostics,
- etc:
Below module config file.
What are your thoughts on that?
I'm really open to suggestions, such as what you would like to have, your thoughts, or inspiration from what you find useful in other tools you use.
2/
Feel free to ask for clarification if what I wrote is too blurred. You can also join our Discord and discuss there longer: https://discord.gg/fTpqUTMmVa
3/
See also how it works in Pongo for now: https://event-driven.io/en/pongo_strongly_typed_client/
What I'm doing atm is taking that to next level. Pongo is a storage library, I intend to add more abstractions around modularity and encapsulation.
None of that is meant to be enforced, but more like enabler giving more options. E.g. code generation, integration with OpenApi, AsyncApi, EventCatalog, etc.
Thoughts?
4/4
@oskardudycz I’m not a user of Pongo so take this worth a grain of salt.
Nothing in here looks bad but I don’t have much context. Why did you choose to make these JS/TS files instead of a static data format? Using a general-purpose language can be accessible to audiences who already know it and makes the config more succinct, but also invites complexity into the configs that can impair readability. It also heavily discourages using outside tools to generate config files.
My personal bent these days is https://kdl.dev and I’ve been on the hunt for a place to use it. It has a nice syntax, a schema format, and clear semantics. The downside to using it for a nodejs project is that it would be foreign to your target audience; the upside is that you’d be helping to move the needle away from using JSON, JSONC, and YAML formats, which the industry desperately needs to do.
@jnkrtech technically this format could be made JSON. I chose TS
/JS to make that accessible for the end users. Especially TS (in) can add static typing and help to make a self-learning journey.
I haven’t heard yet about the KDL, soundss like I need to catch up.
Do you know some other similar to recommend or maybe samples of the usage?
Thank you for the honest feedback
@oskardudycz The built-in feedback aspect of TS does make a lot of sense. Intellisense is a real gamechanger.
I don’t know who’s using KDL at the moment, unfortunately, but they do have libraries for working with it in node: https://github.com/kdl-org/kdljs