Template repository for Web Components

[uniqueg]

Is your feature request related to a problem? Please describe.

With multiple repositories (one repo per component), it is considerably more difficult to maintain them, if they don't all follow the same setup / directory structure. Therefore, it will be nice to create a temporary repository based on which all component reposories are created (compare higher-level meta issue #37). The template would provide common settings, files, topics, issue labels and badges/shields, so as to enforce good practices and to allow developers/maintainers and users to more quickly find their way around a given component repository.

Describe the solution you'd like

Create a template repository with the following:

FILES

• [x] README.md template with the following sections (any text already provided in the template MUST be retained and MUST NOT be modified):
  • Title: Human-readable name of the component, e.g., “TRS-Filer client”
  • Synopsis: Short paragraph describing the functionality of the component in some more detail than the repository description. Use URLs to link out to the most important resource(s) for the component.
  • (add more sections)
• [x] LICENSE plus corresponding badge placeholder in README.md
• [x] .gitignore file listing artifacts common to component development (but should not include artifacts that are specific to a particular developer’s toolbox, such as IDEs/editors; these should be set up by the user globally or on a per-project basis)
• [x] CONTRIBUTING.md; should contain a welcoming message indicating that the project is open for community contributions (can be based on this) and should contain the finalized guidelines as drafted here
• [x] CONTRIBUTORS; should make use/be ready to support the All Contributors specification
• [ ] ESLint configuration
• [ ] Prettier configuration
• [ ] Lerna configuration
• [x] CODE_OF_CONDUCT.md, based on the Contributor Covenant Code of Conduct
• [x] Issue templates
• [x] Pull request template

SETTINGS

• [x] general settings
• [ ] branch settings
• [x] pull request settings

TOPICS

• [x] Front end
• [x] Web Components

See https://github.com/topics for component-specific topics

ISSUE LABELS

• [x] add lables

Additional context Add any other context or screenshots about the feature request here.

It is not clear yet whether repositories from templates retain settings, topics and such as rules for merge requests etc. If not, we might be able to write code that uses the GitHub API to create new repositories off the template and then set it up with useful settings (but that would be a separate issue). We can still list the desired settings here.

We could also consider using Cookiecutter to parameterize some parameters, such as the eventual name of the repository, the copyright year etc. See here for an example: https://simonwillison.net/2021/Aug/28/dynamic-github-repository-templates/

[uniqueg]

The repository has been created and some of the list items addressed: https://github.com/elixir-cloud-aai/wc-template For the missing parts, please open individual issues in that repository and close this issue once we are happy.

[uniqueg]

Btw, for templating some strings I have used {{web-components.NAME_OF_VARIABLE}}, so I am expecting that we will create a Cookiecutter for rendering them later (meaning that we will use a script to create new repos, not the GitHub UI and just select the template). That way we can configure settings as well via the GitHub API, because I'm pretty sure it won't work with just the template repository.

[anuragxxd]

Yeah @uniqueg that sounds good! Also, I think I can first start the work on the children/core components like form, dropdown, etc.

[uniqueg]

Hmm, okay. But until we have the template repository ready, it probably makes most sense to keep the code/logic be for multiple components in a single repo, then migrate it to one repo per component after we have a good setup. And we might as well use the existing web-components repo for that, rather than starting a new one (not based on the template), because it will just create additional overhead, without having the benefit of being one of a set of repos with uniform structure.

For the same reason it's probably good to wait with creating the core repo. Also because I really don't know yet what will be in there. With Cookiecutter templating and calls to the GitHub API, we can probably set up most stuff that is common across components. The problem with just having a template though is that if we update the template, the looks or behavior of existing repos based on that template won't automatically change. The idea of the core compement, which can be compiled/packaged/distributed and then imported would be to achieve exactly that: you update the core component (from which every component inherits) and you can update the behavior of each component in a uniform way by just updating the version of the imported core component - just like we do for FOCA in the backend services.

So for the core component we need to think which properties (looks, behavior, whatever) we want to keep uniform and easily updatable across repos. Things that every component needs, like style sheets maybe, or auth management.

So, to be honest, I'm not too sure if it makes too much sense to code away now on more components. Rather, I think we should put in some work into making sure we have a good design for the process of creating new repos that enforce good practices and have common, consistent behavior where it makes sense. Then afterwards creating new components will be a lot easier, because many questions on design, packaging, testing, documenting etc. will all have been answered to a large extent, and we can just focus on the business logic, mostly.

So I'm thinking whether we shouldn't look at the components that are already there first and extract from there the learnings that inform the design of the the template and the core component.

It doesn't mean that we have to have a perfect template and perfect core component and that we can't do anything until we are at that stage. But I think at least the basic process should be in place: GitHub API calls to set the repo settings that enforce merging policies. Cookiecutter for the easy generation of new component repos based on some light templating. Some common styles that can be inherited from the core component that ensures a consistent design. Just the basics, we can always learn/add more once we feel more comfortable with the setup and find maybe more things that would benefit from additional consistency.

[anuragxxd]

Yeah Alex, that sounds good to me. Then maybe I can work on the template repo so that we can move forward with other things.

[uniqueg]

Okay, looking at a somewhat similar project and discussion with @git-anurag-hub, we think it's better to use a single "monorepo" for all components, managed by Lerna. No need to worry about repo consistency. Of course that also means that we won't need the templating. Instead, we need to implement all of the things listed in the original post in the monorepo (so any work we have done so far wasn't wasted). So I guess we can just start and make the https://github.com/elixir-cloud-aai/wc-template repo the monorepo, as it's already set up with a lot of these goodies, like settings, labels, topics etc. Once we are ready to go and have set up Lerna, we can successively migrate components from this repo.

I will leave this issue open for a while, but let's create individual issues for each of the remaining things on the list in https://github.com/elixir-cloud-aai/wc-template, such as @tanya17-05 already did.