Consider splitsh

[brandonkal]

Would you consider moving vale style development here and then using something like splitsh to create read-only mirrors? This would allow for a more integrated development workflow. The reason I am requesting this is that the docs for errata-ai/Microsoft

Download the latest release, copy the "Microsoft" directory to your StylesPath, and include it in your configuration file

That doesn't appear ideal in a git environment. If all the development was instead done here and the Microsoft directory was split into its own git mirror (without the tests etc), it would simply be a matter of using git submodules or git subtree commands to keep those rules updated (on the consumer side). Meanwhile, all the tests can exist here in this repo as the single source of truth.

Reference: https://github.com/splitsh/lite This is used with success by the PHP symfony framework e.g. https://github.com/symfony/asset

[jdkato]

1. Assumptions aside, this doesn't make sense to me. You want to take a selection of unrelated (and, in many cases, incompatible—it wouldn't make sense to use both Microsoft and Google for instance) repositories, combine them into one monolithic repository, and then use splitsh to split them up again?
2. This suggestion ignores the intended purpose of this repository: It aggregates Vale-compatible, but otherwise unrelated styles for use with Vale Server (which handles installation and keeping styles updated). This is similar to how, for example, text editors manage their community-built extensions—the idea is to allow users to search for and install styles that are built for different purposes, (potentially) maintained by different developers, and hosted in different places.

---

The motivating factor here seems to be that you want to use Git-related tooling to keep the Microsoft sub-directory updated without having to work with the repository as a whole? If so, I think the key is to view the Microsoft sub-directory as a versioned artifact of the repository—not a component that you'd want to check into version control.

This, IMO, is a far better consumer experience when it comes to keeping styles updated:

• If your using Vale with a CI service, I've written a blog post about one technique for staying up-to-date: The Vale Workflow.

• If your using Vale locally, you can use Vale Server or simply pull the latest release from GitHub using a script (Bash, Python, etc.) that can easily be integrated into a Git workflow.

[brandonkal]

1. Yes. i.e. this repo would have the appropriate subdirectories for each project, for instance:

   packages/
   -- Microsoft/
   ----Microsoft/ <-- this is mirrored (distributed via git)
   ----features/
   ----tests/
   -- Google/
   -- IBM/
   -- write-good/

   The fact that these are incompatible is the reason I am suggesting this here. You can't clone into an existing directory because there will be conflicts. You can't clone directly into a styles directory because as far as I can tell, Vale does not support that. So you have to write and manage a separate shell script to copy files over and do what could be easily done with git if things were organized in a way to benefit the consumers of these libraries.

2. I don't see how that is ignoring that purpose. It doesn't preclude others from maintaining their own repositories.

Regarding your third point it is not clear what you mean here. With git submodules (and alternatives) you are only checking in a reference to which commit to download. The code is not checked into the consuming repository.

---

Anyways, this is my suggestion, take it for a grain of salt. As it is now, checking out the repository somewhere disposable and manually copying (and noting elsewhere the the current version) is not a pleasant DX to do or automate with a script. I am not sure how it was concluded that this is a better consumer experience. Having a script always fetch assets in the CI just adds another point of failure, and using Vale server only adds to the complexity with little benefit in this case (not saying it is not valuable). The software is otherwise very good, but I do feel this is an area for improvement.

[jdkato]

I don't mean to discredit your idea -- I genuinely try my best to understand and accommodate the needs of users. That said, here are my final thoughts:

1. I'm not trying to be rude, but I don't think your understanding of how Vale and Vale Server work is thorough enough to be this confident about suggesting a significant project re-structure. There are legitimate trade-offs here and there's a reason why, as I mentioned above with text editors, most plugin/extension systems don't do what you're suggesting.

2. You can't clone directly into a styles directory because as far as I can tell, Vale does not support that.

   You can. Clone the entire Microsoft repository into StylesPath and it'll work as you intend. v1.0.0 may report some (insignificant) warnings (depending on the top-level structure of the repo), but v2.0.0 will work normally unless --debug is passed.

3. So you have to write and manage a separate shell script to copy files over and do what could be easily done with git if things were organized in a way to benefit the consumers of these libraries.

   Regarding your third point it is not clear what you mean here. With git submodules (and alternatives) you are only checking in a reference to which commit to download. The code is not checked into the consuming repository.

   I understand that you feel one option is "easy" and another is a significant burden, but I don't exactly agree -- in fact, I feel almost the opposite: I don't think third-party styles should be viewed as a VCS dependency of a project anymore than, say, the Vale binary (which I assume you don't use Git to manage). But, assuming you're okay with cloning the entire repo, point (1) above should fall into the "easy" category.

4. I don't see how that is ignoring that purpose. It doesn't preclude others from maintaining their own repositories.

   That's exactly the idea here: Microsoft, Google, etc., are the other repositories. I just don't treat styles that I maintain differently than styles that, for example, you could contribute to this repo.

5. Having a script always fetch assets in the CI just adds another point of failure, and using Vale server only adds to the complexity with little benefit in this case (not saying it is not valuable).

   I disagree here, too, but that's okay. I'm glad you've found some use for my OSS software.