Replies: 1 comment 1 reply
-
|
I think you bring up some good points and for the sake of developer ergonomics, we should consider updating the naming structure for all existing repos. The swag repo can be updated without issue, but curious if the hot.opensauced.pizza will break on redirects since it was already renamed from hot-sauce. Perhaps we can do a planned rename right before a release is cut just to make sure. |
Beta Was this translation helpful? Give feedback.
-
Have this covered for a long time, you can play around with something like 0-vortex/4-stars-are-not-enough and check the name in the GitHub API 🍕 |
Beta Was this translation helpful? Give feedback.
-
Working on tooling some repositories in @open-sauced I came to the conclusion that some naming patterns could improve GitHub org navigation as well as npm usage for ourselves and potential ecosystem applications using our packages.
Will list the main categories of interest with some (hopefully) sensible suggestions and motivation for doing so 🍕
🖥️ Public Frontends
Our public frontends are mostly React applications with dockerized nginx builds, there's some duplication at the moment in regards to the
*.opensauced.pizzasubdomain pattern, but there are some advantages to keeping this naming pattern for additional future fully qualified domain names.Repositories that fall under this category:
Some obvious changes here would be:
open-sauced/swag.opensauced.pizzaopen-sauced/hot.opensauced.pizzaWould suggest keeping
open-sauced/open-saucedas the original repository and brand name, mostly due to the limitation of us keeping the reusable workflows in there. If we move these workflows into open-sauced/.github and/or expand with another domain, it would make a lot of sense to then rename toopen-sauced/opensauced.pizza📦 NPM Packages
Our npm packages are tooling enhancements that generally release a ghcr container mirror, platform binary or a GitHub action, depending on their use case; our tooling soon supports doing all 3 steps for every package we release. The main considerations here are ease of use across different registries and in the case of abstract packages, additional naming relevance.
Repositories that fall under this category:
Proposed changes:
@open-sauced/commit- it's pretty obvious by runningnpx @open-sauced/committhat we are invoking an npm flavoredgit commitalternative, expanding this into a container or action would keep the current naming relevant but it feels likecommitis much cleaner@open-sauced/release- after a lot of internal debate this is the best name for this hybrid npm package, docker container and GitHub action, without keeping this one simple it's unlikely to get any attention for the utility it provides@open-sauced/check-engines- got nothing here🛠️ Future proofing everything else
Feel like everything that starts off as a dedicated GitHub action should just have the suffix
-actionFeel like everything that starts off as an API should just have the suffix
-apiFeel like everything that integrates some way across different platforms, generally automation and webhooks, should have the suffix
-integrationAnother easy one but going for the additional dash in the
-botsuffix to remove the branding/personalisation limitation of having each bot named in a catchy way; the repository can host a relevant name while different environments can release branded builds by designAnything that remotely resembles infrastructure, public or private, should be accurately prefixed with the scope like
helm-something,terraform-something,packer-something,docker-examples, etc.@open-sauced/triage naming things, always a popular subject, what do you think?
🍕🍕🍕
Beta Was this translation helpful? Give feedback.
All reactions