🚀 Feature: Presets

[drupol]

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Do you think it's feasible to implement presets? Here's a practical scenario to illustrate the concept:

As a NixOS contributor and pull request reviewer, I use custom replies in my GitHub configuration to expedite my review process. My goal is to enhance the review quality and maintain these configurations in a central, easily accessible location without necessarily committing them to the main NixOS repository. To achieve this, I propose the idea of configurable presets.

Consider the following preset examples:

1. NixOS Preset: {name: "NixOS", location: "https://github.com/foobar/bar"}
2. Rust Preset: {name: "Rust", location: "https://github.com/another/one"}
3. Foobar Preset: {name: "Foobar", location: "https://github.com/foo/bar/replies.yml"}
4. Local Preset: {name: "Local", location: "/home/foo/bar/replies.yml"}
5. ...and more as needed

The key feature here would be the ability to seamlessly enable or disable these presets. For instance, while reviewing NixOS, I could activate the NixOS preset to access all predefined replies from a specific repository configured in that preset. Similarly, when reviewing another project, I could simply deactivate the NixOS preset and enable another relevant one. This flexibility would allow for quick and efficient utilization of context-specific replies.

I'm eager to hear your thoughts on this concept and its potential implementation.

Additional Info

No response

[JoshuaKGoldberg]

Yeah this sounds like a good idea! I can definitely empathize with the use case. There's a lot of prior art in other tools with extended other configs, such as ESLint plugins, Prettier configuration sharing, and TypeScript TSConfig extends. 👍 on moving forward with it in refined-saved-replies as well.

Clarifying questions we'll need to answer:

• How does the equivalent look for refined-saved-replies? Something in the .github/replies.yml file?
• What happens if a config extends a config that extends another config?
• Should configs be able to be dynamic based on some characteristics of the repo and/or page being visited?

[drupol]

How does the equivalent look for refined-saved-replies? Something in the .github/refined-saved-replies.yml file?

I don't have a point of view on this, more information is welcome.

What happens if a config extends a config that extends another config?

Good question, I haven't thought about that yet.

Should configs be able to be dynamic based on some characteristics of the repo and/or page being visited?

It would be super nice to have dynamic placeholders indeed.

---

More thoughts:

How about keeping it simple at first.

Let's analyse the current behaviour of the extension:

1. I browse a Github project
2. If it contains a file .github/replies.yaml, take its content, and add it to my own existing replies in the "Saved replies" box.

The new proposal behaviour would just do the same, except that it would load replies from different places at the same time.

For example, the default preset configuration would be:

1. Default preset: {name: "Current repo", location: ".github/replies.yml"}

This would by default load the file from <current-repo>/.github/replies.yml of the current repository. This is, actually, the default current behaviour.

Now, my idea is to have the possibility to add or remove presets, but also to enable or disable them, as such:

1. Default preset: {name: "Current repo", location: ".github/replies.yml", enable: true}
2. NixOS preset: {name: "NixOS preset", location: "https://github.com/drupol/NixOS-reviews/replies.yml", enable: true}
3. Foobar preset: {name: "Foobar preset", location: "https://github.com/bar/foobar/replies.yml", enable: false}
4. Local preset: {name: "Local preset", location: "~/.replies.yml", enable: true}

With that preset configuration, the extension would load the replies only from these locations:

1. <current-repo>/.github/replies.yml
2. https://github.com/drupol/NixOS-reviews/replies.yml
3. ~/.replies.yml

All the gathered replies would be added to the list of "Saved replies", with or without a prefix to find them easily (to be discussed).

What do you think?

[JoshuaKGoldberg]

Default preset: {name: "Current repo", location: ".github/replies.yml"}

Where is this being set/stored?

[drupol]

I guess Browser extensions can have settings stored somewhere?

[JoshuaKGoldberg]

Funny, I came into this discussion thinking more about allowing the .github/replies.yml file to specify an extends: or similar. But this is about augmenting the extension itself to load in from other presets. Both are good ideas IMO.

• What is the purpose of the name field in the preset examples?
• What happens if multiple presets and/or the repo's main replies.yml specify the same name?
• What, visually, does the interface for setting extension options look like? (as simple as possible)

Once those questions are answered I think we can accept a PR.

We should also note that this extension also supports Firefox now (#7 -> #177). So any UI proposal here should work in Chrome, Firefox, and also be able to extend to Edge (#224) and Safari (#225).

[drupol]

But this is about augmenting the extension itself to load in from other presets. Both are good ideas IMO.

Yes I think this could definitely augment the extension, it has a lot of potential.

What is the purpose of the name field in the preset examples?

The name of the preset in the UI for example.

What happens if multiple presets and/or the repo's main replies.yml specify the same name?

The unique key should be the location key, there's no reason to load twice the content of a replies file.
The indexing key should be numeric, not the name.

What, visually, does the interface for setting extension options look like? (as simple as possible)

I've never designed any extension and I don't really do Javascript, so I'm afraid I won't be of any help in here.