OpenAPITools / OpenAPITools/openapi-generator

[REQ] Document what the folder structure is

Open
#7,069 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

As a new contributor, I find this repo's structure to be very unintuitive and confusing.

It's hard to find the files I need to modify. The important ones, like the mustache templates for each generator are nested 6 layers deep, under parent folders that aren't clear.

For example, imagine you're a user who's just generated some code with this tool.
You spot an error in the generated code, so you want to fix it in the template in this repo.

Where do you go?
Since the templates have different file names to the output files, I can't just use find ./ -name blah

The top level README has no documentation for contributing.

Let's look at the top-level folders.

/bin - what's this? Binaries shouldn't be checked in to a git repo. Opening it up I see it does not contain binaries, so I don't know why it's called /bin. Maybe because the scripts can be called like binaries. But that sounds like the kind of thing which should go into /scripts. So what is in /scripts? Just one obscure file, hmm.

What else do we have? modules is probably right.
What's inside that? Oh, 6 folders that contain the name of the repo. That seems redundant.

There's one that is exactly the name of the repo. We're looking for the core of this project, so that could be it. But there's also core. So is that the core? What's the difference? What about cli? We use the cli to generate the code, is that what's in there?

Ok, let's choose the core one because that sounds like what we want.
Click, click, click.
openapi-generator/modules/openapi-generator-core/src/main/java/org/openapitools/codegen/
Ok now we're 6 layers within core and I still can't see what this is for.

api, a ha! That sounds like what we want.
Hmm, nope.

Ok, back up to the core one that wasn't called core.

Click, click, more nesting of folders for seemingly no good reason.

Ok now we have a choice of 2.

Ooh, codegen sounds like what we want. Let's go 4 layers deeper to get that.

Ooh, I see languages and templating. Both look promising.
Clicking on languages I see that's not what I want.
Ok, let's try templating.
Oh, there's a mustache folder. That sounds like exactly what we want ... except it's not

Ok, let's go back up and try the resources folder.

Ah, this is what we were looking for.

Describe the solution you'd like

  1. The top-level README should have a section on contributing, including a bit that says that if you just want to modify a template, start here.
  2. Folders like this one should have a README.md which explains what each of the sub-folders are. Note that github displays nested READMEs just like the top-level one. I would write a PR for this myself, but I still have no clue what the difference between those folders is.

Describe alternatives you've considered

This is a common problem that plagues most projects. (e.g. the Ansible repo has a folder in it called ansible. It's not obvious what's in it vs out of it.)

I'm yet to come across a better solution than READMEs in subdirectories, and links to common folders from the top-level README.

Additional context

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the top-level README and the modules directory, then inspect the referenced template path at modules/openapi-generator/src/main/resources. Document how the top-level folders and modules differ, and explain where contributors should look when modifying generator templates. Done means the README and relevant nested folders provide clear navigation for these tasks.

Written by the indexing model from the issue text.

Assessment

Domain
developer-experience, documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.