feat: hierarchical config

[FredrikMWold]

Describe the feature

Use case

I work across multiple projects, and while having one configurations for every projects works, it could be streamlined. For instance, I could have a company registry and share configurations for folders under that company without requiring every repository to include a jsrepo config file.

Proposed Solution

Implement staged configuration, where jsrepo looks for config files hierarchically (e.g., project → company → global) and allows the closest file to override higher-level settings.

Validations

• [X] I have checked other issues to see if my feature was already requested or added

[ieedan]

Are you able to give a better example of the file structure here I am struggling a bit to understand. And you mean the jsrepo.json not the jsrepo-manifest.json?

[FredrikMWold]

I'm approaching this feature from a project perspective, using jsrepo.json files to manage configurations. Here's an example of how I imagine it working:

Global Configuration

• I create a jsrepo.json in my home directory to define general settings, such as:
  • Enabling the watermark: "watermark": true
  • Using Prettier as the formatter: "formatter": "prettier"

Company-Specific Configuration

• In a folder dedicated to a specific company, I create a jsrepo.json that sets the registry to one specific to that company:
  • "repo": "company-specific-registry"

This allows me to use the CLI for any project under that company without needing to check in a jsrepo.json file, in case the team lead prefers not to include one in the repository.

Project-Specific Configuration

• For a specific project, I create a jsrepo.json where I set up additional configurations, such as:
  • "paths": {...}

CLI Configuration Priority

The CLI would prioritize configurations based on proximity to the working directory, overriding settings with the closest jsrepo.json. For example:

• Project-level configurations override company-level configurations.
• Company-level configurations override global configurations.

[ieedan]

So basically you want to be able to do something like?

/home
├── jsrepo.json
├── ...
└── my-company
    ├── jsrepo.json
    ├── ...
    └── project
        └── jsrepo.json

How does this avoid checking in a jsrepo.json though? You would still need one to configure paths for the project.

You could try instead using zero-config adds where you fully qualify the block like:

npx jsrepo add github/ieedan/std/utils/math

It would ask you where you want to place the block and whether or not you'd like to include tests and add the watermark.

[FredrikMWold]

You won’t need to check in a jsrepo.json file to a project repository. If you use the CLI in a project that doesn’t have its own jsrepo.json, the CLI will "look up" to the nearest available jsrepo.json (such as one in the company folder) and apply the configurations from there, allowing you to select settings as needed.

That said, without a jsrepo.json in the project itself, certain features—like path mappings—won’t be fully functional. I see this approach as a form of progressive enhancement: You get the full experience, including path mappings, when a jsrepo.json is present in the project. However, if it's missing, you can still use the CLI effectively with just the company-level configuration.

[ieedan]

If you are doing this why not just check in the jsrepo.json though? Better to do that then to have a bunch of files hanging that you have no clue where they came from. If your coworkers wanted the same experience in this scenario they would need to replicate your config files so that they can also add and update blocks. It seems less of a burden to just check the file in in that case so that everyone's on the same page no?

[FredrikMWold]

I prefer using this approach because I frequently switch between projects, and I have components that I use often. This method fits perfectly with my preference to avoid the overhead of an npm package. However, in my experience, some team leads prefer not to have extra configuration files in the repository that they don't personally use.

I'm not sure what you mean by "hanging files." This is something I already manage for Git the samw way. I have a global .gitconfig for general settings and a specific .gitconfig in each company folder with settings unique to that company, allowing me to customize configurations per project or team.

[ieedan]

This is possible I just don't really think it makes sense to implement. jsrepo does support zero-config adds albeit with limited functionality.

The jsrepo.json should probably be treated more like the components.json in shadcn/ui where it isn't really optional to check it in or not. You expect it to be there so that everyone has the same experience working on the project.

I think having nested configs especially configs with required properties is going make it difficult for users to reason what they need to supply and what they don't since the schema has to be wide open for that to work.

[FredrikMWold]

Is the plan moving forward for the zero-config CLI to incorporate more option flags to align with the properties in jsrepo.json? So that it would be possible to bypass the cli wizard.

I ask because one of the things I really like about the shadcn CLI (and this one) is actually the opposite of what you're suggesting. What I appreciate is that I can use it without requiring anyone else on the team to learn or understand it. From their perspective, they simply see an implementation—like a radix-ui dialog—that they can modify as they would any regular component.

This approach works well because when the jsrepo person (me) eventually leaves, the rest of the team can treat the output as standard components, without needing to understand the tool used to generate them.

While I agree that having everyone on the team adopt the tool would be ideal, it’s not always a realistic option.

[ieedan]

We should be able to work on aligning zero-config with the jsrepo.json properties currrently instead of using flags it just prompts you for the options.