@davidlj95/website

👋 Welcome to my small place in the web 🏠

Tooling

This project was generated with Angular CLI version 16.2.0.

To start

First, run the data command, to generate data files that are required for the app to work

pnpm run data

Development server

Run ng serve for a dev server. Navigate to http://localhost:4200/. The application will automatically reload if you change any of the source files.

Code scaffolding

Run ng generate component component-name to generate a new component. You can also use ng generate directive|pipe|service|class|guard|interface|enum|module.

Build

Run ng build to build the project. The build artifacts will be stored in the dist/ directory.

Remember to run the data generation scripts first

Running unit tests

Run ng test to execute the unit tests via Karma.

Running end-to-end tests

Run ng e2e to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.

Commit message guidelines

Commit messages follow the conventional commits guidelines. This allows for automating the release process. By bumping the version depending on the type specified in the commit message. See release for more info.

Commit message lint

To enforce that, commitlint is used. It reads the commit messages on a PR and ensures they follow conventional commits convention.

You can use the following run script to ensure the last commit follows the guidelines:

pnpm run commitlint:last

Lint

Linting is enabled via Angular ESLint which adds some nice ESLint default configurations for Angular projects. Some additions are done in top of that to lint more files, package.json, Jasmine & Cypress... Run the linter for the whole project via:

pnpm run lint:code

By default, Typescript typed linting will not run for performance reasons. Except on CI/CD and when using IntelliJ-based IDEs like WebStorm. You can run the full suite of lint rules including typed ones by using the following command:

pnpm run lint:code:typed

Release

Release It! is used to automate the release process. With the conventional changelog plugin in order to automatically decide which kind of bump to perform (major, minor, patch) based on unreleased commits' messages.

For every push to main branch, Release It! will run and check if a new release is needed. In case it is, a git tag will be assigned to that commit and a GitHub release will be created containing the built app as an asset.

Config has been tweaked so all commits appear in the release notes. To do so, types of commits included are all of the available in Conventional Changelog. But none is hidden. That list comprehends all commit types that commitlint will lint.

Getting release info

In order to embed release information in the app, a script runs to export that kind of information using Release It!'s programmatic API.

To generate the release info, go to scripts directory and run

pnpm run generate:release-info

It will generate a release.json file in the source directory of the app containing the:

• Commit SHA
• Current release version & CHANGELOG
• Unreleased changes CHANGELOG

Checkout the script for more information.

Git hooks

Not a fan of, but it's useful to enforce conventional commits & format your code before submitting it

To use it, run

pnpm run git-hooks

It will install Git hooks via husky. Now everytime you commit, you'll be sure commit message guidelines are enforced.

This is very useful if you can push to main directly. Because there's no way to reject commits that don't follow the commit message guidelines. And once you push to main, you cannot amend that commit as per branch protection rules.

Autogenerated files from templates

Some metadata about the app (like title, author, theme color...) was repeated across files. So used LiquidJS to create template files (.liquid extension). Then, created a small script to render templates into generated files using metadata defined in metadata.ts file (and some hardcoded constants in the generation script)

If you update some metadata in that file, run the script to update files generated from templates. Otherwise, you won't see those changes.

Quirks

Preview deployments

Can only be triggered by users with write access to the repo (to prevent secrets from being leaked). Same secret is used for production access, so better keep that one safe.

Also, branch names should be short. Otherwise, the canonicalUrl may be incorrect, given we try to generate the URL following docs about it in Cloudflare Pages docs. But the exact algorithm to generate the preview URL from branch name is not published. Empirically, it is known that branch names get shorten if they exceed a certain length.

See #289 for more info.

Rendering font subsets

Some fonts included are a subset of a big font file. Before doing anything, please go to scripts directory and run

pnpm run generate:font-subsets

To generate them. Otherwise, those fonts won't be found and you may get some errors. Also, remember to run it if changing the glyphs included in each font. Or to add the new glyphs if you want to use more glyphs of a font.

CI/CD

GitHub Actions are used

Commands ran by CI/CD

In order to ease running CI/CD commands locally, the .ci directory contains a Makefile intended to contain all commands that will be run in CI/CD pipelines. So you can test those locally easily

Just:

cd .ci && make unit-test # for instance

And see how a command run in the CI/CD behaves locally. Notice your machine's state may differ from the CI/CD machine one. Not all commands are there, only the ones that differ from regular package.json run scripts.

Further help

To get more help on the Angular CLI use ng help or go check out the Angular CLI Overview and Command Reference page.