refactor: codegen config schema property moved to the codegen config package.

[SH4LIN]

What

• This PR will refactor the common codegen config code to the @snapwp/codegen-config package.

Why

• This refactoring is to avoid code duplication and keeping the minimal code on the userland

Related Issue(s):

• Part of: https://github.com/rtCamp/headless/issues/303

How

• Added withCodegenConfig function which will extend the base config with the custom configs provided from the individual codegen.ts file.

Checklist

• I have read the Contribution Guidelines.
• My code is tested to the best of my abilities.
• My code passes all lints (ESLint, tsc, prettier etc.).
• My code has detailed inline documentation.
• I have added unit tests to verify the code works as intended.
• I have updated the project documentation accordingly.

[justlevine]

What does a wrapper function give us that object destructuring doesnt?

[SH4LIN]

We are now moving the schema into our codegen package. If we continue using only the object, it incorrectly retrieves process.env values. To resolve this, I converted it into a function called baseConfig(), which first loads the process variables from individual .env files. After that, it calls the function, ensuring we get the correct process.env values.

For the withCodegenConfig function, we are following the same approach as we did for withSnapWP. We take the config from the userland codegen.ts, give it higher priority, and add our common configs, such as HOC. This ensures that all extensibility functionality remains intact.

This HOC approach allows us to modify internal functionality and update functions without requiring users to migrate between versions.

For example, suppose we added the generateGraphqlUrl function in the userland codegen.ts and released the Next.js starter. Developers start using it, but later, we decide to change this function and introduce a new architecture. In that case, we would need to create a migration guide instructing users to adopt the new approach—despite them having no prior knowledge of the change. Additionally, we would have to follow a deprecation process for something that is purely an internal functionality.

[justlevine]

I don't like that we've removed the entire schema.

There are many reasons that a project will need to change this, e.g. to change/add headers. (it's also one of the reasons I think the generateGraphQLUrl function should be removed).

[SH4LIN]

There is still an option to override this by passing it as the config in withCodegenConfig function

[justlevine]

Yes, but a user would need to override the entire property...

[SH4LIN]

Can you give me an example of what you mean by an entire property?

If you say they cannot override the schema property completely, they can. However, they won't be able to keep the schema property as our default and only change the header.

[justlevine]

#45 (comment)

If I needed to set the origin header in my local project, I would need to:

• navigate the monorepo to find the defaults.
• copy the defaults into my local codegen config
• add my origin header.
• actively monitor or changes to the default codegen config.

[justlevine]

Still don't like this. I feel like there is a difference between defaults and abstractions, and we really don't want to be creating an abstraction.

Will defer to @ayushnirwal

[justlevine]

Need some clarification on the approach 🙇

[SH4LIN]

@justlevine I have made changes to the code please re-review it, meanwhile I'll resolve merge conflict

[justlevine]

Some nitpicks, but then I think I need to defer to @ayushnirwal . I feel like we're adding tech-debt here without gaining anything.

Might help to see it with the merge-conflict resolved, since that's where the first pass of codegen types start getting added.

[justlevine]

Still don't like this. I feel like there is a difference between defaults and abstractions, and we really don't want to be creating an abstraction.

Will defer to @ayushnirwal

[ayushnirwal]

We are abstracting away the choice of a schema file or endpoint right now. This seems good enough solution to solve our problem of CI depending on a server.

The real solution is to manage this choice in the scaffold process or let the Users decide by exporting 2 configs one using schema file and other using an endpoint. That being said it is out of the scope of a pre-alpha release. Given the choice between a stability and ease of use. I would prefer to choose the later option now and move on.