Modelina config file

[jonaslagoni]

Reason/Context

This is probably one of the most important features to this date, because this will enable better integrations across tools. Because while Modelina is highly customizable, it is almost impossible for CLIs and other tools to offer those advantages because many of the configs are callbacks where you can overwrite logic. Therefore I think it would make sense to add configuration file support where the customizations can be placed .modelina.js

This means that users can customize their models outside the scope of any integration, for example:

• Our AsyncAPI CLI where users could pass a config file such as asyncapi generate models --config ./.modelina.js
• Our AsyncAPI generator, if templates use Modelina to generate the data models you could pass alongside your own extended configuration file for the templates to use. I.e. asyncapi generate fromTemplate asyncapi.json @asyncapi/ts-nats-template --param modelinaConfig=./.modelina.js.

These config files should be simple JS files that expose a default js object which is taken as the options for the generator i.e.

const {TS_COMMON_PRESET} = require('@asyncapi/modelina');
module.exports = {
  presets: [
    {
      preset: TS_COMMON_PRESET,
      options: {
        example: true
      }
    }
  ]
}

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[jonaslagoni]

I cant figure out if this feature should be solved in Modelina or the respectful integrations such as the generator and CLI. Made a proof of concept for the CLI to trigger the discussion in the next community meeting.

https://github.com/asyncapi/cli/pull/430

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[jonaslagoni]

Still on the roadmap 😄

[kaushik-rishi]

@jonaslagoni I would be very much interested to take this issue up. I totally understand the requirement for this issue.

[jonaslagoni]

Sure!

So I actually managed to get it working in the CLI, check out this PR: https://github.com/asyncapi/cli/pull/430

However, we need to move the logic to Modelina instead and add better error handling, tests, etc.

We have to figure out how to change the API of Modelina i.e. propose how the generator methods would look like when providing the options as a file path.

Furthermore, because we are working with files (i.e. something a website cannot handle) we have to adapt the file generators and not the regular generator.

I would suggest you start small, create a single method that takes the configuration as a file path, load the configuration (i.e. import the file), and call the other generator functions with the right options.

Let me know if this makes sense and give you a starting point 👍

[kaushik-rishi]

@jonaslagoni Finally it should allow removal of the logic to include the config file from the CLI. this is what i understand, Is it right ? :thinking:

[kaushik-rishi]

I see the PR isn't merged yet :thinking: I'm a bit confused here.

[jonaslagoni]

The PR in the CLI was just a proof of concept, the functionality needs to be located within Modelina itself instead, i.e. that you can load the configuration from a javascript file 🙂

[kaushik-rishi]

I've understood the issue now. Should it be an option wether to take the config from the js file or not, or should it take the config right away if the file name matches ?

[jonaslagoni]

I would focus on the explicit config file for now.

We can always add the implicit config file lookup later if it makes sense, we just don't know exactly how it will be used yet.

[kaushik-rishi]

Also, @jonaslagoni will the introduction of this feature, mean we donot need to add more and more flags to modelina / cli ? like --tsMarshalling etc etc or would we need to keep both of those in sync ?

Makes sense to keep both the features working (config file and flags), like we can have the flags in some places like github actions / any automation scripts where the config file approach would be more hectic. :slightly_smiling_face:

Am I right ?

[kaushik-rishi]

@jonaslagoni

Furthermore, because we are working with files (i.e. something a website cannot handle) we have to adapt the file generators and not the regular generator.

Can you clarify what we mean by this ?

I understood that to accomodate the new change, we will have to change the api of AbstractGenerator. I did'nt quite get what we meant by the above quoted line :thinking:

[jonaslagoni]

@kaushik-rishi I assume I already answered these questions somewhere else, otherwise do let me know, cause then I simply missed them 🙏

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[AnimeshKumar923]

still valid? @jonaslagoni