feat: create command templates generates a .github directory in the repository root instead of always in the output directory

[BeatriceMitchell]

As as developer who is generating code with VG CLI, I want the resulting .github directory to be created in the correct location, So that dependabot and workflows operate properly.

[superiorsd10]

Hello @BeatriceMitchell 👋 Could you please describe the expected behavior or outcome of this issue in more detail? This would help me better understand the issue.

Thank you,

[alestiago]

Hi @superiorsd10!

I will add some reproductive steps here so it helps illustrate the issue.

1. Create a new directory:

mkdir my_very_good_project

2. Start a git project on your new directory:

git init my_very_good_project

4. Create a new project using Very Good CLI (from my_very_good_project):

very_good create project_a

5. Create another new project using Very Good CLI (from my_very_good_project):

very_good create project_b

The generated output has a folder structure as:

my_very_good_project -- project_a ---- .github ---- [...] -- project_b ---- .github ---- [...] -- .git

Sometimes, when working with monorepos if the git project is on the parent folder the user might desire the output to be as follows: my_very_good_project -- project_a ---- [...] -- project_b ---- [...] -- .git -- .github

This is essentially what the issue is suggesting, merging all child .github directories into the root of the project when possible and desired.

---

Note that this is not a "good first issue" and it requires some not-straightforward work. If you're willing to work here I'm more than happy to assign you (please drop a comment). I suggest starting by writing a proposal and describing how do you anticipate solving this issue. For example, you can start by answering the following questions:

• How will merging .github directories occur? What if two workflows have the same file name? Will the CODEOWNERS file be merged respecting the CODEOWNER file structure and not simply appending? Are tools already out there that handle this merge logic?
• How will the user interface with this new solution? Will the existing create command have a new flag? Will the detection be automatic? How do we plan to detect that the user is in a monorepo?

[omartinma]

@alestiago thanks for all the steps. Here are my thoughts.

Why not simply have a flag that allows you not to create the .github folder? I might see 2 different use cases here:

• A regular user in a mono repo who wants to add an additional package. I believe if that is the case they might have already it in the root folder a .github folder, so they will not need it. The only thing they might need is a specific yaml file for this new package something like new_package.yaml that points to the path of the new package.

• A user generating an isolated package. If that is the case yes, we need for sure the .github package as we normally do as well on any very_good create.

So maybe a flag saying if isRoot or not?

[alestiago]

Thanks for chiming in @omartinma. In my honest opinion, I think we should not simply ignore generating the "github" folder. There is value on some of the files generated, like for example the new workflow (as you pointed out) for the new package and many more (see table below).

---

Proposal

1. Find the nearest .git file system entity
2. Populate the .github directory at the same level as the git file system entity with the workflow for the new package

This would solve both use cases, including adding the "specific workflow yaml file" when the package is being generated in the mono repository (which the isRoot flag and ignoring the .github directory doesn't solve).

The only thing to consider is resolving conflicts. Here is a conflict resolution algorithm (draft) for each of the .github generated files:

File System Entity	Conflict resolution
dependabot.yaml	Respect the "version". Add new entries to the "updates" list with relative paths specified in the "directory" entry. Enable "enable-beta-ecosystems" if not already enabled and new "updates" entries use a beta ecosystem.
cspell.json	Verify that the "schema" has the correct value, if not overwrite. If it is correct, only add the Very Good allowed and forbidden dictionaries if not already there.
PULL_REQUEST_TEMPLATE.md	Overwrite completely, the end user decides if to commit or revert the new change.
ISSUE_TEMPLATE/config.yaml	Ensure "blank_issues_enabled" is disabled.
ISSUE_TEMPLATE/bug_report.md	Overwrite completely, the end user decides if to commit or revert the new change.
ISSUE_TEMPLATE/feature_request.md	Overwrite completely, the end user decides if to commit or revert the new change.
workflows/project_name.yaml	Rename the file by suffixing a _1, _2 until there is no conflict. Update the paths to be relative to the new package.

[omartinma]

@alestiago the main concern that i have is that this yaml generated is way too different on how we will approach this for a package, so it is not simply moving the file but updating few things inside like the paths and removing the semantic and spell check since the main.yaml should have all of that.

About the table that you specified, I would not overwrite. If a new user, for example, didn't setup anything on the main app but now wants to use the CLI for the package, then it will create the file, but, if the user has already a file i dont see why we should overwrite.