Changelog for the collection of template repositories for new projects.

0.11.0

Improvements

Opt-in Dependabot version update configuration — #94 ⇄ #95 (⊶ d34de53d)

↠ The .github/dependabot.yml Dependabot configuration file for automation version updates that was introduced in #52 often causes a lot of PR noise and does not really help since updates also often require more action than just a bump of the version number itself like migration steps or adjustments to changes (e.g. APIs or deprecated implementations). Since Dependabot is not able to fulfill this and only does a stupid increase of the version number it often creates more work than it helps. The result are often hundreds of notifications and more digital noise for developers and maintainers without any real benefit since version & security updates are done on a regular schedule by maintainers who know what they are doing and how modern software should be maintained. Therefore the .github/dependabot.yml file has been renamed to .github/dependabot.tmpl.yml to disable Dependabot for this repository while still allowing repositories that are based on this template repository to opt-in.

0.10.0

⇅ Show all commits

Improvements

Migrate to Markdown style guide version 0.4.0 — #76 ⇄ #77 (⊶ 0bb40e35)

↠ This project adheres to the Arctic Ice Studio Markdown style guide which recently published version 0.4.0 that introduces some larger changes:

The repository was converted into a monorepo and the currently used remark-preset-lint-arcticicestudio npm package was deprecated and moved into the new, scoped @arcticicestudio/remark-preset-lint package.
Support for the shiny new remark version 13.0.0 was introduced which is now the minimum required version for the rule preset packages.
Several other great improvements and migrations like the adaption of this template repository as well as the usage of the GitHub Flow branching model and new main branch concept.

Optimize GitHub action workflow scope — #84 ⇄ #85 (⊶ 079bd3d7)

↠ Currently all jobs are summarized in the ci workflow but not separated by their scope, e.g. only Node specific tasks. The workflow is also not optimized to only run when specific files have been changed which results in false-positive executions and wastes limited free tier and developer time. Therefore the ci workflow will be optimized.

CI Node

A new ci-node workflow will…

only run when any *.js, *.json, *.md, *.yaml and *.yml file has been modified. This matches the lint-staged, Prettier and remark configurations. See the extensive GitHub action documentations about on.<push|pull_request>.paths and the filter pattern cheat sheet for more details.
only run for ubuntu-latest instead of a matrix with macos-latest and windows-latest since there is no platform specific code yet.
use cache npm dependencies which is possible as of actions/setup-node@v2.2.0.

Tasks

Update Node packages — #78 ⇄ #79 (⊶ 0f13e87d)

↠ Updated all outdated Node packages to their latest versions:

lint-staged — Bumped minimum version from v10.5.4 to v11.0.0.
prettier — Bumped minimum version from v2.2.1 to v2.3.2. It comes with the nice improvement to treat the .prettierrc file as YAML when formatting it.
Validated and fixed/improved matches after running formatting and linting tools with their latest versions.

Bump actions/setup-node from 2.1.5 to 2.4.1 — #83 (⊶ d516b492)

↠ Updated actions/setup-node from version 2.1.5 to 2.4.1.

Update Node package dependencies & GitHub Action versions — #86 ⇄ #87 (⊶ f97b7e52)

↠ Updated all repository (development) Node packages and GitHub Actions to the latest versions and adapt to their changes:

husky — Bump minimum version from ^6.0.0 to ^7.0.4 where 7.0.0 is a major update that allows to remove the .husky/.gitignore file to simplify the local installation and usage.
lint-staged — Bump minimum version from ^11.0.0 to ^12.0.4 where 12.0.0 is a major update that allows ESM usage.
prettier — Bump minimum version from ^2.3.2 to ^2.4.1.
remark-cli — Bump minimum version from ^9.0.0 to ^10.0.0.

0.9.0

⇅ Show all commits

Improvements

From npm to Yarn and back again — #72 ⇄ #73 (⊶ b9967864)

↠ Some years ago, the switch from npm (v4) to Yarn (v1) was mainly done because of the fantastic workspace feature for monorepos as well as the great performance and UX improvements. This was a good decision and almost every popular and well-known project used to do the same, but with the announcement of Yarn v2 (named “berry“) the community got upset about the path the project has taken. Next to this, npm joined GitHub back in March 2020 which meant that the development continues in a good direction and is baked by the open source platform itself. These events, the overall fantastic new npm release version v7, including the introduction of workspaces, and the fact that I never liked the disadvantage of requiring to use an “external“ package manager instead of the one that is bundled with Node, lead to the decision to finally switch back to npm again.

The only drawback is the constraint that the minimum npm version is now v7.7.0 because this is the first version that comes with workspace support for the run-script and exec commands through the --workspace/-w and --workspaces/-ws CLI flags, e.g. npm run -w PACKAGE run lint. The first Node version that ships with npm v7.7.x is v15.13.0 which is globally available as of april 1, 2021 (no, it‘s not an april fool 😄). To ensure that these constraints are met, without only relying on users to read the documentation, both npm and node have been added to the engines field of the package.json file.

This change also comes with updates to all documentations, including the addition of the version constraints, as well as updates to repository template features like the GitHub Action workflows. The .yarnrc file has been replaced by .npmrc that includes the package-lock=false and save-exact=false configurations.

Tasks

Node package dependency & GitHub action version updates — #67, #68, #69, #74 ⇄ #75

↠ Bumped outdated Go module dependencies and GitHub actions to their latest versions:

#67, #68, #69 (⊶ 8bff7a5d, 46a92f0a, 14a9108e) actions/setup-node from v2.1.2 to v2.1.5
#74 ⇄ #75 (⊶ d827dbf5) husky — Bumped minimum version from v4.3.0 to v6.0.0. This also includes some breaking changes that require migrations. Run the official migration CLI to automatically migrate from v4 to v6: npx husky-init && npm exec -- github:typicode/husky-4-to-6 --remove-v4-config
#74 ⇄ #75 (⊶ d827dbf5) lint-staged — Bumped minimum version from v10.5.1 to v10.5.4.
#74 ⇄ #75 (⊶ d827dbf5) remark-cli — Bumped minimum version from v8.0.1 to v9.0.0.

Dependency handling with lockfiles — #70 ⇄ #71 (⊶ a98d9b1c)

↠ The usage of dependency lockfiles like package-lock.json or yarn.lock has always been a controversial topic where opinions go in different directions. On one side many project maintainers tend to argue that is helps to achieve deterministic build results, but on the side it might also hide problems when any later versions of a used dependency, or its transitive dependencies, is not compatible with the own project anymore.

I‘ve investigated a lot of time into research again to finally find a solution that works for my projects. In short, the result is to go with the rule that is also used by many large-scale projects: Do not use lockfiles for multi-consumer projects like libraries but only for single-consumer projects like applications.

Therefore the yarn.lock file has been removed since this makes no sense for a repository template anyway. See the sections below for some more details about how to decide to use a lockfile or not.

When to use lockfiles

The clear advantage of lockfiles are reproducible builds and the persistence of a running project state. They ensure that a project artifact can be rebuild at anytime using the exact same dependencies, resulting in the exact same artifact, even when the project was not updated in years. This applies to projects that are focused on building a end-to-end experience like applications and other end-user products.

These are the advantages listed in the official npm documentation about package-lock.json files:

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.

Facilitate greater visibility of tree changes through readable source control diffs.

Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.

Like mentioned, npm v7 comes with a lot of advantages and the team recommends to commit the file into project repositories:

the lockfile has enough information to describe the precise package tree all by itself.
the lockfile maps the packages to their information by their relative location to the root (instead of their name).
the npm CLI uses yarn.lock lockfiles if available, as a source of package metadata and resolution guidance when there is missing information, knowing that the package-lock.json is the authoritative definition.
- yarn.lock lockfiles cannot completely replace npm’s lockfile since the current implementation doesn’t have enough information needed for the complete npm functionality.
the npm CLI uses a “hidden lockfile“ placed inside the node_module directory that helps to avoid repeated package tree reading.

Another point is that in end-user projects dependencies in package.json files are often pinned instead of using SemVer range selectors like ^ (latest minor-only) or ~ (latest patch only). In such cases a lockfile helps to keep control about transitive dependencies and persist projects states in time.

When to avoid lockfiles

Even though the Yarn team published a blog post in 2016 that states to always commit the yarn.lock file, regardless of the project type, this advice was not adopted by every project and some “real-world scenarios“ often showed that this decision was justified. There are blog posts that summarize when not to use a lockfile where even Yarn maintainers reply with comments that claim the opposite, but over the time more and more projects went away from using lockfiles. One argument is that lockfiles are important to enure that library contributors in 10 years still know what was the last confirmed set of packages which worked as expected, but this can almost be ignored in a ecosystem like Node that changes almost every day.

Another important point is to mention that the usage of lockfiles were also a attack surface to inject malicious dependencies. Due to the large size of lockfiles, it is also often a challenge for project maintainers to review and validate a lockfile in pull requests are so they are often ignored and blindly trusted.

The community is still not of one opinion and I guess this will never change, but learning about the experience of well-known maintainers and popular projects is often a good way to find the own decision.

In conclusion, the usage of lockfiles in a non-end-user project can be well summarized with “just postponing the inevitable breakage“:

0.8.0

⇅ Show all commits

Improvements

Reduce Dependabot PR noise for NPM package ecosystem — #65 ⇄ #66 (⊶ 32925a1f)

↠ To reduce the noise of too many PRs from NPM dependencies, where most of them are only scoped for (local) development, two optimizations have been made:

The schedule changed to the monthly interval. This is still enough to keep up with the fast updates in the NPM ecosystem.
Only watch production packages (dependencies) and ignore development packages (devDependencies). The packages used for local or CI/CD development purposes are not required to be the latest version just for the sake of being up-to-date without a specific need or benefit.

Since GitHub takes security really serious, important Dependabot security updates are triggered manually by a security advisor so there is no risk of missing important versions bumps when reducing the schedule interval.

Use the allow option to customize which dependencies are updated. This has no impact on security updates for vulnerable dependencies.

Tasks

Prepared project/repository publication — #59 ⇄ #60 (⊶ 50238339)

↠ Before switching the GitHub repository visibility to “public“ a few adjustments had to be made. Basically #22 was reverted, taking the changes from #23 into account, so that SVG images like the repository hero are using the URLs for public repositories again instead of the ones that allow to resolve the files in private repositories.

Node.js package dependency version updates — #63

↠ Bumped outdated Node.js package dependencies to their latest versions:

#63 (⊶ 35287545) prettier from 2.1.2 to 2.2.1 — The the official Prettier 2.2 introduction blog post for more details.

0.7.0

⇅ Show all commits

Tasks

Updated to latest Node.js package dependency & GitHub Action versions — #54,#55,#56,#57

↠ Bumped outdated Node.js package dependencies & GitHub Actions to their latest versions:

#54 (⊶ 41e11b94) actions/setup-node from v1 to v2.1.2 — v2 comes with speed and performance improvements by using a dedicated, built-in image cache for Node.js distributions.
#55 (⊶ d1e3d538) lint-staged from 10.2.11 to 10.5.12
#56 (⊶ 22652c51) husky from 4.2.5 to 4.3.0
#57 (⊶ 17378a12) prettier from 2.0.5 to 2.1.2

0.6.0

⇅ Show all commits

Feature

Initial project documentation — #50 ⇄ #51 (⊶ f18bf434)

↠ Wrote the initial project documentation for the README.md file that includes…

…an project introduction and motivation.
…an overview of the project features.
…a listing of available template repositories.
…a rough overview of the directory structure.
…more detailed sections about all features.
…some basic instructions how to use this template repository.
…information about how to contribute to this project.

Dependabot: Automated dependency updates and security alerts — #52 ⇄ #53 (⊶ 4816e4ec)

↠ In June 2020 Dependabot was natively integrated into GitHub. This allows to use automated dependency updates and security vulnerability alerts.

Created the dependabot.yml file and configured updates for GitHub Actions and Yarn/NPM. The documentation also mentions the need to manually enable or disable Dependabot per repository.

0.5.0

⇅ Show all commits

Improvements

Use namespace for NPM package name — #48 ⇄ #49 (⊶ 85f0b08c)

↠ To prevent collisions with already existing NPM packages like tmpl the NPM package name of this repository has been changed to use the @svengreb namespace prefix.

0.4.0

⇅ Show all commits

Improvements

Optimize OS version matrix strategy for CI workflow — #46 ⇄ #47 (⊶ cb772586)

↠ Before the CI workflow used a matrix strategy to run the lint-node job, but this was not necessary for this repository. It has been improved to make the workflow run faster by avoiding unnecessary steps. The lint-node job has been changed to only run on the currently latest stable Node version 14.x only on Linux because this repository is not focused on JavaScript but only runs Node based tools to lint other files within this repository.

This change also helps to keep the required GitHub Action run minutes for the account of this repository as small as possible without wasting resources for unnecessary tasks.

0.3.0

⇅ Show all commits

Improvements

Pin version to v2 for actions/checkout in CI workflow — #44 ⇄ #45 (⊶ 5d2ce0c0)

↠ Before actions/checkout was used from the master branch in the ci workflow. This has now ben pinned to the latest version v2 to ensure a stable pipeline.

0.2.0

⇅ Show all commits

Features

Git ignore pattern for Yarn and JetBrains products — #39 ⇄ #40 (⊶ 5d2ce0c0)

↠ Before there were only ignore pattern for the Node.js node_modules folder, but specific pattern for Yarn were missing. Because the fantastic JetBrains products like Goland (or respectively IntelliJ with the official Go plugin) are an integral part of my daily toolbox the pattern have also been added.

Improvements

More fine-grained GitHub Action trigger configuration — #34 ⇄ #35 (⊶ c184ae8b)

↠ The CI GitHub Action Workflow used the push setting for the on field in order to trigger the workflow. That was superficial and the workflow ran for every new commit and PR.

To improve this behavior and prevent unnecessary workflow runs the push field of the on field is now configured to only run for the main branch and v* tags while the pull_request field is set without any specific configuration so that it runs for all PRs regardless of the target branch.

Lowercase naming for GitHub Action workflows — #36 ⇄ #37 (⊶ e53fbaf8)

↠ Even though it is possible to use uppercase names (including whitespaces) for GitHub Action workflows it is best practice for almost every language to use lowercase names. This prevents problems with parsing as well as errors due to lower- and uppercase mismatches.

One example is the shields SVG badge that is used in the README of this repository: The actual workflow is only found when the name matches the exact notation including lower- and uppercase characters To mitigate such problems the name has been changed to lowercase only.

Maximum line length for Markdown EditorConfig — #41 ⇄ #42 (⊶ 6c1a2ac9)

↠ Since Markdown is written as flowing text the globally defined maximum line length of EditorConfig has been disabled to prevent false-positive errors.

Bug Fixes

Fix missing LF EOL definition in Git attributes — #38 ⇄ #43 (⊶ 01d4aee3)

↠ The comment for the * text=auto rule in the .gitattributes file documents the usage of LF for EOL, but the actual eol=lf property was missing.

0.1.0

⇅ Show all commits

This is the initial release version of tmpl. It represents the basic project setup, structure and development workflow. There are many initial configurations and documentations that are covered in the following sections of this version changelog to introduce used technologies and explain why several decisions have been made.

Features

Initial repository README and assets — #1,#21/#22,#23 (⊶ 0b0d7aee)

↠ The main branch stores documentations and assets about the This introduces the README.md with basic content as well as the projects logo and repository hero assets. It will be extended later on with more project information and usage instruction for the different template repositories.

Yarn and NPM package configuration — #2 (⊶ a1788097)

↠ Created the package.json and .yarnrc configuration files to declare and setup Node tools. This includes the usage of the Yarns exact version resolution. Since Yarn is used npm's package-lock.json file will never be created and tracked in order to prevent conflicts with the yarn.lock file.

MIT license — #3 ⇄ #4 (⊶ 1ec34446)

↠ Added the LICENSE file for the MIT license. This includes the main branch since the file covers the content of the repository itself and is also part of the base template.

Git ignore and attribute pattern — #5,#24 ⇄ #6,#25 (⊶ cd509de1)

↠ Added the .gitattributes and .gitignore configuration files to define the pattern.

Git mail mapping — #7 ⇄ #8 (⊶ )

↠ Added a Git mailmap file to link to in documentations to allow contributors to send mails regarding security issues. This prevents unnecessary overhead of updating all documents when new core team and members and contributors are added and additionally adds the main functionality of the file: Mapping commits when someone changed the email address or uses a different one.

Git mail mapping — #7 ⇄ #8 (⊶ 68a9ee81)

↠ Added a Git mailmap file to link to in documentations to allow contributors to send mails regarding security issues. This prevents unnecessary overhead of updating all documents when new core team and members and contributors are added and additionally adds the main functionality of the file: Mapping commits when someone changed the email address or uses a different one.

GitHub code owners — #9 ⇄ #10 (⊶ 960c939f)

↠ Adapted GitHub's code owners feature. This allows to define matching pattern for project paths to automatically add all required reviewers of the core team and contributors to new PRs.

See GitHub documentation for more details.

Sidebar for code owner PR review requests and review stats

Branch protection configuration to enable required code owner review approvals

PR status checks when required code owner review is pending

EditorConfig — #11 ⇄ #12 (⊶ 0745977d)

↠ Added the editorconfig file to define and maintain consistent coding styles between different editors and IDEs.

Code Formatter: Prettier — #13 ⇄ #14 (⊶ 196cdf2e)

↠ A code formatter is a essential part of a project setup to ensure a good and consistent code style without requiring relatively time-consuming manual corrections found by a code linter. With code being automatically formatted on actions like saving a file the developer can focus entirely on the code instead of spending time and energy on indenting code line by line.

That‘s where one special project comes in: Prettier, the opinionated code formatter with support for almost any language and integration with almost every popular editor. I‘ve been using it since the first version and I totally forgot about the fact that formatting is even a thing. That could also be because Gophers are already used to gofmt anyway.

Prettier is a absolute must-have for every project setup and I‘m not aware of any other projects with such advanced parsers and language support. The only negative point is that it is written in JavaScript instead of Go so it always pulls in Node as a development dependency. This is not a problem at all for web-based projects, but for Go or any other non-NodeJS project it inflates the setup unnecessarily.

Anyway, the fantastic developer experience and project benefits clearly outweigh the negative points. In addition many developers today already have Node installed locally since it‘s large ecosystem has already spread by far further than just the web but already powers many system, desktop and CLI applications.

Configuration

This is one of the main features of Prettier: It already provides the best and recommended style configurations of-out-the-box™. The only option that was changed is the print width. It is set to 80 by default which is not up-to-date for modern screens (might only be relevant when working in terminals only like e.g. with Vim) and has therefore been changed to 120 like defined in all of my style guides. The prettier.config.js configuration file is placed in the project root as well as the .prettierignore file to also define ignore pattern.

Package Script

To allow to format all sources a format:pretty package script has been added that also runs in the main format script flow. The new lint:pretty script allows to check if all supported files are formatted correctly. It is included in the main lint script flow.

Markdown Linting: remark-lint — #15 ⇄ #16 (⊶ 552dded0)

↠ Ensuring that documentations and content written in Markdown are of great quality should be a continuous goal of any project. Persisting information is a consistent and extensive way helps tp keep a project healthy, no matter whether for long-time or new users ad well as maintainers and contributors. Linting Markdown results in better rendering with different markdown parsers and makes sure less refactoring is needed afterwards.

The best solution for this task would be a tool written in Go, but the undisputed best tool is still remark-lint which is (unfortunately) written in JavaScript and used via Node. Of course there are fantastic projects written in Go like goldmark that provides a great way to parse content, but linting is (currently) not a feature. remark-lint on the other side is built on top of remark, the powerful Markdown processor powered by plugins (such as remark-lint itself) and part of the unified collective. It comes with really large set of customizable rule and ways to ensure Markdown will be consistent across any project.

Another decision point for remark-lint was the fact that Prettier has been added in #13 to this template so Node is already a development dependency anyway. This also allows to add other awesome projects that are (unfortunately) written in JavaScript and for which there is no comparable alternative.

Configuration

remark-lint can be used via remark-cli and a rule preset. This preset is remark-preset-lint-arcticicestudio, my custom preset that implements my Markdown Style Guide. Since the custom preset is still in major version 0 the version range should be >=0.x.x <1.0.0 to avoid the “SemVer Major Zero Caveat”. When defining package versions with the the carat ^ or tilde ~ range selector it won‘t affect packages with a major version of 0. Yarn will resolve these packages to their exact version until the major version is greater or equal to 1. To avoid this caveat the more detailed version range >=0.x.x <1.0.0 should be used to resolve all versions greater or equal to 0.x.x but less than 1.0.0. This will always use the latest 0.x.x version and removes the need to increment the version manually on each new release.

The .remarkrc.js configuration file is placed in the project root as well as the .remarkignore file to also define ignore pattern.

Package Script

To allow to run the Markdown linting separately a lint:md package script has been added and included in the main lint script flow.

Git Hook: lint-staged — #17 ⇄ #18 (⊶ abae9c23)

↠ Git Hooks are a fantastic way to customize the development workflow of a project to simplify and automate specific tasks that are required when working on the code base. For example, this includes tasks like formatting, linting and running tests before pushing a commit to ensure it conforms to the code style and works as expected. Most Git Hooks are not that complex and fullfil a simple purpose while other solutions like danger can help to manage larger projects and projects that need to scale.

This base template repository will initially use a Git Hook that automatically runs configured linters on all files that have been staged and that match the configured pattern (file extension, filename etc.). Like documented in #15, Node is already a development dependency anyway so the lint-staged NPM package will be used for this goal. I‘ve used this package in almost any project and it‘s again the most stable, production-proven and advanced tool that is currently out there with no comparable alternatives in other languages.

Configuration

The configuration file lint-staged.config.js is placed in the project root and includes the command that runs for matching file extensions (globs). It includes at least the three following entries with the same order as listed here:

prettier --list-different - Runs Prettier (#13) to ensure all files are formatted correctly. The --check prints files that are not conform with the Prettier configuration.
remark --no-stdout - Runs remark-lint (#15) against *.md to ensure all Markdown files are compliant to the style guide. The --no-stdout flag suppresses the output of the parsed file content.

Git Hook Manager & Runner: husky — #19 ⇄ #20 (⊶ 49d1fac0)

Git hooks made easy 🐶 woof!

↠ In #17 lint-staged was added, a Git Hook runner that runs linters against staged files before each commit. To automatically run this and other hooks that might be added later on, the hook manager and runner husky is used.

Just like other already added tools (GH-13, GH-15, GH-17), husky is (unfortunately) also written in JavaScript. Since Node is therefore already a development dependency it doesn‘t really matter that husky is another NPM package too. Unlike these previous tools there are indeed alternatives written in Go like lefthook or quickhook, but it requires time to test and evaluate them before actually replacing husky. Also a long as there are no comparable alternatives to the already used tools listed above, this template would be more complex by requiring both Node and Go as development dependency. Therefore husky will take over the part as hook manager & runner since it is a stable, production-proven and advanced project that I already use in almost any other project setup.

Configuration

The .huskyrc.js configuration file is placed in the project root and includes the command to run for any supported Git hook. Initially it contains an entry for the following hook:

pre-commit - Runs lint-staged (#17) before each commit to ensure all staged files are compliant to all style guides.

Git Hook Manager & Runner: husky — #19 ⇄ #20 (⊶ 49d1fac0)

Git hooks made easy 🐶 woof!

↠ In #17 lint-staged was added, a Git Hook runner that runs linters against staged files before each commit. To automatically run this and other hooks that might be added later on, the hook manager and runner husky is used.

Just like other already added tools (GH-13, GH-15, GH-17), husky is (unfortunately) also written in JavaScript. Since Node is therefore already a development dependency it doesn‘t really matter that husky is another NPM package too. Unlike these previous tools there are indeed alternatives written in Go like lefthook or quickhook, but it requires time to test and evaluate them before actually replacing husky. Also a long as there are no comparable alternatives to the already used tools listed above, this template would be more complex by requiring both Node and Go as development dependency. Therefore husky will take over the part as hook manager & runner since it is a stable, production-proven and advanced project that I already use in almost any other project setup.

Configuration

The .huskyrc.js configuration file is placed in the project root and includes the command to run for any supported Git hook. Initially it contains an entry for the following hook:

pre-commit - Runs lint-staged (#17) before each commit to ensure all staged files are compliant to all style guides.

GitHub "CI" Action Workflow — #28 ⇄ #29 (⊶ b4e3c396)

↠ Using GitHub Actions brings many advantages like a „close-to-the-source“ development pipeline. Having the code and automated pipelines/workflows in one place is worth a lot. This also comes along with the perfect and smooth integrations into GitHub platform and page itself like status reports on PRs and many more possibilities like the customization and triggering of workflows through webhooks for almost every event that can occur in a repository/issue/PR etc.

The GitHub Actions CI/CD UI

See the official GitHub Actions documentation for details about setups, features, the configuration API and many more!

Live logs showing real-time feedback

The initial implementation focuses on continuous integration to the Node.js scripts with Yarn that are defined in the package.json file.

There is official support for SVG badges, but in order to use the same custom configurations and style of already included badges the ones provided by shields are used.

GitHub Open Source community standards — #30 ⇄ #31 (⊶ 9495d3cc)

↠ GitHub introduced a feature for recommended community standards. tmpl tries to adhere to the great Open Source Guides and adapted to the recommendations to complete the projects community profile.

Code of Conduct

To facilitate a healthy and constructive community behavior, tmpl adheres and enforces a code of conduct.

It includes sections about

what we believe in and how we act
unacceptable behavior
the responsibilities of the maintainer
the enforcement of the Code of Conduct
consequences for violations
the scope of the Code of Conduct

See the GitHub documentation for more details about the provided integrations.

Contributing Guidelines

The contribution guidelines help to build a community that encourages people to use, contribute to, and evangelize a project.

It will include sections about

how to get started
bug reports
enhancement suggestions
pull requests
style guides
credits

See the GitHub introduction blog post and GitHub documentation for more details about the provided integrations.

GitHub issue and pull request templates — #32 ⇄ #33 (⊶ 0bc90483)

↠ GitHub provides a feature to define multiple issue templates.

The initial template file that has been used when the feature was introduced can now be used as a fallback/generic template.

The UI helps users to open a new issue in projects by prompting them to choose from multiple issue types.

See the GitHub documentation for more details about issue and pull request templates. Also check out how to manually create issue templates and a pull request template. There's also a guide on how to create the (deprecated) fallback/generic issue template.

Improvements

Improve per-file documentations — #26 ⇄ #27 (⊶ 2acd89ec)

↠ Some files contained comments with details about the file content as well as references to documentations and websites. These have been improved by simplifying the way how references are listed, removing unnecessary content as well as moving comments to the places in the file where they are relevant.

Files

CHANGELOG.md

Latest commit

History

CHANGELOG.md

File metadata and controls

0.11.0

Improvements

0.10.0

Improvements

CI Node

Tasks

0.9.0

Improvements

Tasks

When to use lockfiles

When to avoid lockfiles

0.8.0

Improvements

Tasks

0.7.0

Tasks

0.6.0

Feature

0.5.0

Improvements

0.4.0

Improvements

0.3.0

Improvements

0.2.0

Features

Improvements

Bug Fixes

0.1.0

Features

Configuration

Package Script

Configuration

Package Script

Configuration

Configuration

Configuration

Code of Conduct

Contributing Guidelines

Improvements