DEV Community: Yoriiis

Why I built vLitejs, a fast and flexible native video and audio player

Yoriiis — Sun, 07 Dec 2025 20:44:00 +0000

Nearly a decade ago, I started exploring ways to build lightweight and flexible video players. While working on client projects, I realized that existing libraries were often too heavy, difficult to customize, or included features that not everyone needed.

This experience inspired the creation of vLitejs (pronounced /viːlaɪt/), an open source project designed to offer a minimal, high-performance video and audio player that can be extended with plugins and providers.

History

The first version of vLitejs was released in 2019, supporting HTML5 video and YouTube. Audio support was added shortly after, along with accessibility and keyboard navigation. Additional providers like Dailymotion and Vimeo were later integrated.

The project has evolved with contributions from the community. Issues and discussions help refine the project. I guide the project's evolution, ensuring decisions follow a clear vision: requests are debated, sometimes implemented as plugins, or occasionally declined to maintain the project's focus, lightweight size, and performance.

Context and motivation

vLitejs was born from the desire to have a lightweight, fast, and flexible player.

At the time, libraries like Video.js and Plyr.js had grown heavy because they accepted perhaps too many requests from their communities, and maintenance became complex. I wanted a solution that stayed small by design while still being extensible when necessary.

The goal was simple: keep the default player minimal and make any extra capabilities optional through plugins.

Design principles and architecture

vLitejs is based on a clear and intentional separation: a minimal core, optional providers and plugins. The core implements only the essentials for HTML5 playback. Providers adapt the player to external platforms (YouTube, Dailymotion, Vimeo) and their SDKs are loaded on demand. Plugins add optional capabilities (PIP, subtitles, cast, hotkeys, etc.) in a scoped way that keeps the codebase modular and reusable.

Key technical choices:

Written in TypeScript for strong typing and maintainability
Delivered as EcmaScript Module (ESM) (inspired by Sindre Sorhus)
Supports recent Node.js LTS releases and modern browsers
Architecture based on a minimal core with opt-in plugins and providers

💡 Each provider inherits from a base Player class, ensuring consistent behavior across playback types. Plugins interact with this class through the public API, extending the player without altering the core.

These architectural rules enable vLitejs to remain compact and easy to maintain.

Features

vLitejs provides a set of practical features designed for both developers and end users, all built around a modular architecture:

Core

HTML5 video & audio by default
Accessibility and keyboard navigation
Customizable control elements
Unified events API

Providers

YouTube
Dailymotion
Vimeo
SDKs automatically loaded

Plugins (highlights)

Picture-in-Picture
Subtitles
Cast & AirPlay
Hotkeys
Sticky player
Monetization (Google IMA SDK)

Advanced

HLS support for streaming
Inline SVG icons

How it works

This section shows how to include and use vLitejs in your pages.

Initializing the player

<video id="player" src="<path_to_video_mp4>"></video>

import 'vlitejs/vlite.css';
import Vlitejs from 'vlitejs';

new Vlitejs('#player');

Providers example (YouTube)

import 'vlitejs/vlite.css';
import Vlitejs from 'vlitejs';
import VlitejsYoutube from 'vlitejs/providers/youtube.js';

Vlitejs.registerProvider('youtube', VlitejsYoutube);

new Vlitejs('#player', {
  provider: 'youtube'
});

Plugins example (PIP + subtitle)

import 'vlitejs/vlite.css';
import 'vlitejs/plugins/pip.css';
import 'vlitejs/plugins/subtitle.css';

import Vlitejs from 'vlitejs';
import VlitejsPip from 'vlitejs/plugins/pip.js';
import VlitejsSubtitle from 'vlitejs/plugins/subtitle.js';

Vlitejs.registerPlugin('pip', VlitejsPip);
Vlitejs.registerPlugin('subtitle', VlitejsSubtitle);

new Vlitejs('#player', {
  plugins: ['pip', 'subtitle']
});

Global events

All events are standardized across providers and plugins. You can listen to common events such as play, pause, timeupdate, and many more depending on the context.

new Vlitejs('#player', {
  onReady: (player) => {
    player.on('play', () => {
      console.log('Video started');
    });
    player.on('pause', () => {
      console.log('Video paused');
    });
    player.on('timeupdate', () => {
      console.log('Current time', player.getCurrentTime());
    });
  }
});

Creating a custom plugin

Developers can create custom plugins to extends capabilities. Plugins are scoped, interact with the player instance, and can be registered via the Plugin API.

For more details, see the Plugin API documentation and Provider API documentation on GitHub. They describe the available lifecycle hooks and best practices for building custom behaviors.

What's next

vLitejs will keep evolving while remaining lightweight and modular. Planned improvements:

Automated E2E tests with Playwright to verify core and plugin integrations
New providers and plugins driven by real user demand
Better documentation and examples for plugin/provider development
Performance monitoring and selective optimizations as needed

Key takeaways

A clear architecture enables optimal performance while keeping the core minimal
Modularity allows customization without overloading the library
Strong TypeScript typing ensures maintainability and reliability
Supports only modern browsers, avoiding unnecessary legacy code
Community input is valuable, but decisions follow a clear vision to keep the project focused and maintainable

Conclusion

vLitejs is a personal open source project that gives you a fast, flexible video and audio player. Its modular design lets you include only what you need: a simple, reliable player by default, with advanced features available on demand.

Discover vLitejs

❤️ Special thanks to Maxime Lerouge for his help at the beginning of the project and Victor Schirm for designing the logo.

Resources

From ESLint/StyleLint and Prettier to Biome: simplifying our front-end linting

Yoriiis — Thu, 27 Nov 2025 21:14:00 +0000

When you work on multiple front-end projects at scale, consistency and automation quickly become key.

At Prisma Media, we wanted every merge request to focus on actual logic changes, not formatting or stylistic details.

We had relied on the classic linting stack: ESLint for JavaScript and TypeScript, StyleLint for CSS and Prettier for consistent formatting.

With VS Code Workspaces configured for auto-format on save, code reviews became cleaner and formatting discussions disappeared.

This article explains how we simplified this stack by migrating to Biome, a single tool that handles linting and formatting across multiple front-end languages.

Challenges with ESLint, StyleLint and Prettier

Before Biome, our front-end projects relied on the classic trio: ESLint, StyleLint and Prettier.

Over time, the linting stack grew to cover more languages and use cases:

JavaScript, TypeScript and JSX/TSX
PostCSS for styling
Markdown for documentation

This diversity came with a high maintenance cost.
Our global configuration alone depended on more than 15 packages 🤯

For ESLint: eslint, eslint-config-prettier, eslint-config-standard, eslint-plugin-import, eslint-plugin-jsdoc, eslint-plugin-n, eslint-plugin-prettier, eslint-plugin-promise, eslint-plugin-react
For TypeScript: @typescript-eslint/eslint-plugin, @typescript-eslint/parser
For CSS: stylelint, stylelint-config-standard, stylelint-prettier
And finally, prettier.

Upgrading one dependency often required adjusting several others. In practice, we planned upgrades of these packages 1-2 times per year to ensure stability. For every update, we had to validate compatibility, update shared configs and fix CI pipelines. Maintaining this stack was becoming increasingly time-consuming and prone to errors.

Migration to Biome

When Biome appeared, the promise was appealing: one tool, one config, multiple languages.
A single binary capable of linting, formatting and analyzing code, with far less setup and impressive performance.

I started by testing Biome on my open source projects to evaluate effectiveness and flexibility, then gradually introduced it into internal front-end apps.
The first results were convincing: Biome matched ESLint, StyleLint and Prettier in functionality, but everything was now configured in a single file instead of juggling multiple configs and parser versions.

A simplified version of our biome.json configuration:

{
  "$schema": "https://biomejs.dev/schemas/2.2.7/schema.json",
  "files": {
    "includes": ["src/**"]
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "tab",
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "css": {
    "formatter": {
      "quoteStyle": "single"
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "asNeeded"
    }
  }
}

This single configuration file replaced the entire ESLint, StyleLint and Prettier stack.

We also updated our VS Code workspace to integrate Biome, enabling format-on-save and automatic code actions:

{
  "settings": {
    "editor.defaultFormatter": "biomejs.biome",
    "[javascript][typescript][typescriptreact][css][json]": {
      "editor.formatOnSave": true
    },
    "editor.codeActionsOnSave": {
      "quickfix.biome": "explicit",
      "source.organizeImports.biome": "explicit",
      "source.fixAll.biome": "explicit"
    }
  }
}

💡 Biome also provides a migration tool to help transition from ESLint and Prettier.

When Biome v2 was released, we quickly migrated. The new plugin API looked promising and offered more flexibility for custom rules.
One feature we immediately started using is the option to organize imports automatically.

Biome in CI/CD

One of the biggest improvements was how easily Biome integrated into our GitLab CI pipelines.
As a single binary, it eliminated the need for multiple npm installs and complex config merges.
Adding linting to a pipeline became as simple as:

biome check .

The performance gain was immediate.
Linting jobs now run faster and more consistently across all environments, reducing CI runtime and minimizing potential inconsistencies between local development and pipelines.

ESLint vs Biome — simplified comparison

Aspect	ESLint + StyleLint + Prettier	Biome
Tools & dependencies	~15 separate packages to maintain	1 single binary
Configuration	Multiple config files & shared extensions	Single `biome.json` file
Performance	Slower: separate tools for JS, TS, CSS, parsing overhead	Faster: unified binary, single parsing pass, lower memory usage
IDE integration	Requires multiple extensions	Single VS Code plugin
Multi-language support	JS, TS, JSX/TSX, CSS via separate plugins	JS, TS, JSX/TSX, CSS, JSON and more to come soon
CI/CD setup	Complex npm-based scripts and merges	Lightweight, single command
Maintenance overhead	High: multiple packages, compatibility checks	Minimal: single upgrade keeps everything aligned

Key notes

After several months using Biome in production, the benefits are clear:

One tool, one config — simpler setup and updates
More thorough linting — immediate feedback in the editor with highlighting and tooltips
Improved onboarding — developers install Biome and start coding quickly
Consistent rules across JS, TS and CSS
Excellent IDE integration out of the box
Accessibility checks included by default

If you are interested in accessibility tooling, check out our related article on

Yoriiis

Nov 12 '25

Improving accessibility for popins: focus trap and keyboard handling

#a11y #javascript #frontend #webdev

Comments

3 min read

Maintaining the front-end stack has become much easier.
Now, a single Biome upgrade keeps linting, formatting and analysis aligned across all projects.

Conclusion

Migrating from ESLint, StyleLint and Prettier to Biome simplified our front-end tooling and unified our workflow, while drastically reducing maintenance overhead.

Biome's evolution and plugin ecosystem provide a solid foundation for our future front-end architecture. Its speed, simplicity and improved developer experience make it an ideal choice for large-scale front-end projects.

Full configuration files and examples are available in GitHub

Discover our Biome config on GitHub

Resources

Improving accessibility for popins: focus trap and keyboard handling

Yoriiis — Wed, 12 Nov 2025 22:28:00 +0000

Keyboard users often encounter issues when interacting with popins, modals, or tooltips. During an accessibility audit with a partner, we noticed that focus can easily escape the popin, leading to a confusing experience.

This approach ensures keyboard users can stay within the popin and interact predictably, improving accessibility and user experience (UX) for all users.

The problem

Popins generally include several interactive elements: a close button, overlay, and main content such as forms or call-to-actions (CTAs). Without proper focus management, users can tab out of the popin into the underlying page, breaking accessibility rules and making interactions unpredictable.

Implementation

Key rules for accessible popins:

Initial focus on the close button

When a popin opens, we save the currently focused element and programmatically set focus to the close button using .focus(). This ensures that keyboard users start interacting with the popin immediately and allows us to restore focus later when the popin closes.

Trap focus inside the popin

Tabulation should only traverse elements inside the popin. The focus remains trapped only while the popin is open. Reaching the last element and pressing ⇥ Tab returns to the first, and ⇧ Shift + ⇥ Tab from the first moves to the last.

When the popin is closed, focus is restored to the element that triggered its opening.

If the popin opens automatically without user interaction, do not move focus; instead, ensure the popin is keyboard-accessible and optionally notify the user via an ARIA live region.

Visible focus styling

Using :focus-visible ensures keyboard users can see which element is active. This pseudo-class only applies when interacting via keyboard, avoiding unnecessary outlines for mouse users.

💡 A good practice is to allow the popin to be closed by pressing the Escape or clicking on the overlay.

Example

Here's a minimal example of a popin with HTML, CSS, and JS implementing the focus trap pattern:

HTML

<div role="dialog" aria-modal="true" aria-labelledby="newsletter-title" class="popin">
  <button type="button" class="popin-close" aria-label="Close newsletter popin">×</button>
  <h2 id="newsletter-title">Subscribe to our newsletter</h2>
  <form>
    <input type="email" placeholder="Your email" required />
    <button type="submit" class="form-submit">Subscribe</button>
  </form>
</div>

CSS

.popin *:focus-visible {
  outline: 2px solid #007acc;
  outline-offset: 2px;
}

JavaScript

class FocusTrap {
  constructor({ container, firstElement, lastElement }) {
    this.container = container;
    this.firstElement = firstElement;
    this.lastElement = lastElement;
    this.previousActiveElement = null;

    this.focusableSelector =
      'button:not([disabled]), [href], input, select, textarea, [tabindex]:not([tabindex="-1"])';

    this.handleKeydown = this.handleKeydown.bind(this);
  }

  init() {
    this.previousActiveElement = document.activeElement;
    this.focusableContent = [...this.container.querySelectorAll(this.focusableSelector)];

    this.firstElement.focus();

    document.addEventListener('keydown', this.handleKeydown);
  }

  handleKeydown(e) {
    if (e.key !== 'Tab') return;

    // Recalculate focusable elements
    this.focusableContent = [...this.container.querySelectorAll(this.focusableSelector)];
    const last = this.lastElement ?? this.focusableContent.at(-1);

    if (!e.shiftKey && document.activeElement === last) {
      e.preventDefault();
      this.firstElement.focus();
    } else if (e.shiftKey && document.activeElement === this.firstElement) {
      e.preventDefault();
      last.focus();
    }
  }

  destroy() {
    document.removeEventListener('keydown', this.handleKeydown);

    this.previousActiveElement?.focus();
  }
}

Key points

Always set initial focus to the most relevant interactive element (usually the close button)
Trap focus inside popins to prevent keyboard users from leaving the overlay unintentionally
Use :focus-visible to ensure the active element is clearly visible for keyboard navigation
Maintain correct DOM order and define tabindex for logical navigation
Include proper ARIA roles and attributes (role="dialog", aria-modal="true", aria-labelledby, button types)
Restore focus to the triggering element after closing the popin
Handle automatically opened popins appropriately (keyboard-accessible, ARIA live notification)
Modularize the focus trap pattern for reuse across multiple popins

Conclusion

Focus management for popins is a small but crucial detail in accessibility. Implementing a focus trap provides a predictable experience for keyboard users and can prevent common accessibility pitfalls.

Thinking about focus management early in your modal design ensures a smoother and more consistent experience for all users, and the pattern is reusable across multiple sites or projects.

Resources

How we test NPM packages before publishing with npm pack

Yoriiis — Sun, 26 Oct 2025 21:54:00 +0000

When working on multiple interdependent NPM packages across projects, testing a new version before publishing is essential.

At Prisma Media, we maintain several packages on our private NPM registry, used directly on our websites. While each package comes with a standalone demo, we regularly need to validate development versions in real environments.

Understanding `npm pack`

Running npm pack builds your package locally and generates a .tgz archive identical to what would be published with npm publish. The archive is created in the current directory and includes only the files defined in the files field of your package.json or filtered by .npmignore.

It's also a convenient way to verify what your package will actually ship before publishing. Inspecting the generated archive helps ensure that only the expected files are included.

Testing options

Developers have a few options to test packages locally:

Local linking: npm link works if both the package and consuming project are cloned locally
Preview or shared environments: npm link fails here. Other options include:
- Publishing a tagged version (like beta), it requires deployment to the registry
- Using npm pack, it generates the .tgz archive that would be published, without touching the registry

We chose npm pack for its simplicity and safety. It allows developers and product teams to test new versions in local or preview environments, without affecting production workflows.

Implementation

Our package pipelines follow a standard sequence: install, build, test, pack and finally deploy.

For details on our reusable GitLab CI template you can read

Yoriiis

Oct 15 '25

Scaling GitLab CI/CD with reusable templates

#devops #gitlab #ci #automation

Comments

5 min read

The npm pack job is manual. When a developer needs a dev version:

Navigate to the latest pipeline of the merge request
Trigger the npm-pack job
The job runs and uploads the TGZ as an artifact
Install and test locally:

Download and extract the artifact
Install the TGZ in your project:

   npm install <path_to_tgz_file>

This replaces the version from the registry with the local TGZ version. Example diff:

   - "player": "1.0.0"
   + "player": "file:player-1.1.0.tgz"

Commit the TGZ file to your branch if you plan to deploy a preview
Once committed, the CI will install the TGZ

GitLab CI template

Here is a simplified .gitlab-ci.yml template for the npm-pack job:

npm-pack:
  variables:
    PACKAGES_DIR: 'npm-pack-packages'
  image: node:22-alpine
  script:
    - mkdir $PACKAGES_DIR
    - PACKAGE_TGZ=$(npm pack)
    - mv "$PACKAGE_TGZ" $PACKAGES_DIR
  artifacts:
    paths:
      - $PACKAGES_DIR
  when: manual

This job generates the TGZ locally and stores it as an artifact. The file can then be installed for local or preview testing.

For the GitHub Actions equivalent

Discover npm-pack workflow examples on GitHub

Advantages

Developers can test packages locally without publishing
The TGZ can be versioned in the dev branch, allowing CI to install it on preview environments
Product teams can validate features before merging

⚠️ Remember: TGZ files are for development and preview only, never for production.

Key points

npm pack replaces npm link for shared or CI environments
When switching back to a registry version, always run npm uninstall <package> before reinstalling
Version TGZ files only for temporary testing; never use them in production
CI pipelines can safely produce TGZ artifacts for local or preview testing
Manual triggering keeps pipelines efficient

Conclusion

Using npm pack to test packages locally or in preview environments simplifies cross-project development. It sits between local linking and full registry publishing, giving developers and product teams a faster way to validate changes.

By integrating this workflow into CI, we can safely validate packages, maintain developer productivity and ensure quality before official publication.

The complete example is available on GitHub for you to try out! 🧑‍💻

Discover NPM pack on GitHub

Resources

Scaling GitLab CI/CD with reusable templates

Yoriiis — Wed, 15 Oct 2025 21:44:00 +0000

Managing dozens of projects relying on GitLab CI/CD templates can be a challenge.

At Prisma Media, on front-end libraries and some Symfony apps, we had a mix of configurations that were inconsistent, hard to maintain, and often not optimized. This article explains how we centralized our GitLab CI/CD pipelines into reusable, modular templates, and how you can adopt a similar approach.

Why a dedicated CI templates repository

The problem: scattered CI configurations

Before reusable templates:

Each project had its own .gitlab-ci.yml with a lot of duplication
Jobs were inconsistent across projects (npm ci vs npm install, different caching strategies)
Pipelines were often slow and hard to debug
Documentation was minimal or missing
Synchronizes updates were complicated to deploy

Our solution: modular templates

We created a dedicated repository (ci) hosting modular GitLab CI templates. Each template:

Handles a single task (install dependencies, build, run tests, publish)
Is optimized (cache, artifacts, retries)
Is fully documented with usage examples and configurable variables
Uses semantic versioning (v1, v2) so projects can upgrade at their own pace

Our templates are stage-agnostic, with no predefined needs or stages, so consumer projects keep full control over their pipeline flow.

Templates also support different working directory, depending on where NPM commands are executed.

💡 Tip: prefix template names (e.g. .npm-install) to avoid conflicts with jobs in the consuming project.

Our template catalog

Template	Purpose	Key features
`npm-install`	Install dependencies	Cache optimization
`npm-build`	Build application	Custom command support
`npm-qa`	Run linter	Custom command support
`npm-unit-test`	Run unit tests	JUnit reports integration
`npm-pack`	Create `.tgz` package	Artifact output
`npm-publish`	Publish to registry	Manual trigger
`create-tag`	Git tag creation	Version auto-detection

Each template is independent and hosted in a dedicated directory with its own documentation.

Pipeline overview

Shared configuration

All templates extend a common.yaml to centralize variables, cache, and default behaviors. This ensures consistency across templates and reduces duplication.

variables:
  MAIN_BRANCH: main
  NODE_IMAGE: node:22-alpine
  WORKING_DIRECTORY: ./

.default:
  variables:
    FF_USE_FASTZIP: 'true' # Optimize cache/artifact compression
  interruptible: true
  artifacts:
    expire_in: 3 days
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

.cache-npm:
  cache:
    key:
      files:
        - ${WORKING_DIRECTORY}/package-lock.json
    paths:
      - ${WORKING_DIRECTORY}/node_modules
    policy: pull

💡 Note on branch rules:
All our templates use $MAIN_BRANCH in rules instead of $CI_DEFAULT_BRANCH.
This ensures the pipeline behaves consistently relative to the versioned branch (v1, v2, etc.) rather than the repository's default branch, which may change over time.

Selected CI templates

Here are a few representative templates; all templates are available in the GitHub repository.

`npm-install`: install dependencies

.npm-install:
  extends:
    - .default
    - .cache-npm
  image: ${NODE_IMAGE}
  cache:
    policy: pull-push
  script:
    - cd ${WORKING_DIRECTORY}
    - npm ci
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == 'merge_request_event'
        || $CI_COMMIT_REF_NAME == $MAIN_BRANCH

`npm-build`: build application

.npm-build:
  variables:
    COMMAND: 'npm run build'
  extends:
    - .default
    - .cache-npm
  image: ${NODE_IMAGE}
  script:
    - cd ${WORKING_DIRECTORY}
    - ${COMMAND}
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == 'merge_request_event'
        || $CI_COMMIT_REF_NAME == $MAIN_BRANCH

`npm-qa`: run linter (Biome)

.npm-qa:
  variables:
    COMMAND: 'npm run test:qa'
  extends:
    - .default
    - .cache-npm
  image: ${NODE_IMAGE}
  script:
    - cd ${WORKING_DIRECTORY}
    - ${COMMAND}
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == 'merge_request_event'
        || $CI_COMMIT_REF_NAME == $MAIN_BRANCH

`npm-unit-test`: run unit tests (Jest)

.npm-unit-test:
  variables:
    COMMAND: 'npm run test:unit'
  extends:
    - .default
    - .cache-npm
  image: ${NODE_IMAGE}
  script:
    - cd ${WORKING_DIRECTORY}
    - ${COMMAND}
  artifacts:
    paths:
      - junit.xml
    reports:
      junit: junit.xml
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == 'merge_request_event'
        || $CI_COMMIT_REF_NAME == $MAIN_BRANCH

💡 The job improves unit test report in GitLab merge request with jest-junit package and GitLab unit test reports.

`npm-pack`: generate local package

.npm-pack:
  variables:
    PACKAGES_DIR: 'npm-pack-packages'
  extends:
    - .default
    - .cache-npm
  image: ${NODE_IMAGE}
  script:
    - cd ${WORKING_DIRECTORY}
    - mkdir $PACKAGES_DIR
    - PACKAGE_TGZ=$(npm pack)
    - mv "$PACKAGE_TGZ" $PACKAGES_DIR
  artifacts:
    paths:
      - $WORKING_DIRECTORY/$PACKAGES_DIR
  when: manual
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

💡 Use this template for local testing before publishing or integration validation. The local NPM package can be installed in your project for testing.

`npm-publish`: publish to NPM registry

.npm-publish:
  extends:
    - .default
  image: ${NODE_IMAGE}
  script:
    - npm publish
  allow_failure: false
  when: manual
  rules:
    - if: $CI_COMMIT_REF_NAME == $MAIN_BRANCH

💡 To publish to a private registry, update the .npmrc file with the registry URL and authentication token before running the publish command.

⚠ As of September 2025, NPM enforces shorter token lifetimes for write operations and plans to retire legacy tokens. To future-proof your CI, consider migrating to Trusted Publishing (OIDC).

`create-tag`: create Git tag

.create-tag:
  extends:
    - .default
  image: node:22-alpine
  before_script:
    - apk add --no-cache git
    - git config --global user.email "gitlab@gitlab.com"
    - git config --global user.name "GitLab CI"
  script:
    - VERSION_NUMBER=$(npm pkg get version | xargs echo)
    - git tag $VERSION_NUMBER
    - git remote set-url origin "${CI_SERVER_PROTOCOL}://oauth2:${GITLAB_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/$CI_PROJECT_PATH.git"
    - git push origin $VERSION_NUMBER
  allow_failure: false
  rules:
    - if: $CI_COMMIT_REF_NAME == $MAIN_BRANCH

💡 Requires a Project Access Token in GITLAB_TOKEN variable.

Final consumer usage

In the consumer project, the .gitlab-ci.yml becomes very simple. The project only imports the templates it needs and defines the dependencies between jobs itself. This keeps the pipeline clean, flexible, and easy to maintain.

include:
  - { project: 'user/ci', file: 'templates.yaml', ref: 'v1' }

workflow:
  rules:
    - if: $CI_COMMIT_TAG # Disable tag pipeline
      when: never
    - when: always

variables:
  WORKING_DIRECTORY: '.'

npm-install:
  extends: .npm-install

npm-build:
  extends: .npm-build
  needs: [npm-install]

npm-qa:
  extends: .npm-qa
  needs: [npm-install]

npm-unit-test:
  extends: .npm-unit-test
  needs: [npm-install]

npm-pack:
  extends: .npm-pack
  needs: [npm-build]

npm-publish:
  extends: .npm-publish
  needs: [npm-build, npm-qa, npm-unit-test]

create-tag:
  extends: .create-tag
  needs: [npm-publish]

Versioning and evolution

We tag template releases (v1, v2, etc.) so teams can upgrade on their schedule. Each release includes a changelog and migration notes for breaking changes. We also use code owners for approval deployment to secure our templates.

Planned improvements:

Consider GitLab CI Components in the future for even better reuse
Extend templates for other ecosystems (Python, PHP) as needed

Results and lessons learned

For the projects that adopted the templates we observed:

Significant reduction in per-repo CI maintenance effort
Faster onboarding for new projects and engineers
More consistent build and publish behavior across teams

Operational notes

Template bugs can affect consumers widely, but fixing a template fixes it for all consumers at once
Adoption takes time: provide migration guides and a short period of backward compatibility

Conclusion

Centralizing GitLab CI templates gives us modular, documented, and versioned building blocks for pipelines. It reduces duplicated effort, enforces sensible defaults, and lets teams focus on product work rather than CI boilerplate.

If you'd like to try the repository and examples, the code is available on GitHub:

Discover our reusable CI templates on GitHub

What's your current CI approach? Have you centralized templates, or do you prefer per-repo pipelines? I'd be interested to read your experience.

Resources

Efficient script loading strategy

Yoriiis — Sun, 28 Sep 2025 22:08:24 +0000

Loading JavaScript efficiently is critical for any website's performance.

At Prisma Media, we made this transition several years ago, and the solution we use today remains reliable and effective across all our sites.

Our pages must load scripts in a defined order while bundling resources efficiently.

The typical sequence is:

Consent management
User connection
Site resources (e.g. styles, scripts)
Third-party scripts (e.g. Google Tag Manager, analytics)

Before 🦖: a JavaScript loader to control execution

Back in 2018 we relied on scriptjs, a small library that lets you load scripts programmatically and control execution order. We placed our calls to scriptjs in a <script> tag just before </body> and listed each resource in the exact order we needed.

But two problems became clear over time:

Performance: page rendering was delayed
Maintenance: the library was no longer actively maintained

Those issues pushed us to rethink script loading entirely.

Back to basics

After moving away from a JavaScript loader, our goal was to rely on the most native browser features possible. The reasoning was simple:

The closer we stay to native HTML and browser standards, the more aligned we are with long-term best practices
We no longer wanted to depend on a third-party library that might require another migration in a few years
The solution had to be sustainable and easy to deploy across all our websites

The obvious choice was to use regular <script src="…"> tags with the right attributes.

As explained brilliantly in Flavio Copes' article on async and defer, the best strategy is to place scripts in the <head> with the defer attribute.

This placement enables scripts to download in parallel while the browser continues parsing. It ensures scripts execute in order after parsing and makes the DOM interactive sooner.

Handling our loading sequence

For scripts such as consent management, user connection, or third-party scripts served from a CDN, the transition was straightforward. We simply added <script defer src="…"></script> in the desired order.

The bigger challenge came from our own resources. Our platform is a multi-page application (MPA), not a single-page app (SPA). Our websites are server-rendered with Twig templates and we use Webpack to package all resources (styles, scripts, etc.).

Back in 2018 we had a single entry point for the entire site. That setup generated a large JavaScript file shared across all pages, even though each page had different needs. There was no code splitting or shared-chunk optimization.

When we decided to rely on native <script> tags, we wanted to align with our MPA architecture by producing page-specific bundles instead of a single monolithic file. Generating the right <link> and <script> tags for each page could not be done manually, so we needed a webpack plugin to generate them automatically at build time.

At that time the popular html-webpack-plugin assumed a JavaScript-based template and didn't fit our needs.

To bridge the gap I created chunks-webpack-plugin: a Webpack plugin that analyzes entry point dependencies and generates HTML fragments with the appropriate <link> and <script> tags.

This kept the approach fully native, just standard <script> elements, while enabling per-page bundles with granular chunk splitting. For details on that optimization step you can read

Yoriiis

May 10 '20

Granular chunks and JavaScript modules for faster page loads

#webdev #webperf #webpack #javascript

Comments

6 min read

💡 Key notes:

Modules: <script type="module"> are deferred by default, the defer attribute is unnecessary
Legacy fallback: use nomodule attribute for polyfills or legacy bundles; modern browsers will skip them automatically
Attribute precedence: if both async and defer are set, modern browsers give priority to async
Inline scripts: async and defer have no effect on inline scripts (those without a src attribute)

HTML rendering

Below is a simplified example of the final markup. Each script follows the execution order described above.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Home</title>
    <script defer src="consent.js"></script>
    <script defer src="user-connection.js"></script>
    <!-- Page-specific bundle generated by Webpack -->
    <script defer src="home.js"></script>
    <script defer src="gtm.js"></script>
  </head>
  <body>
    <!-- Page-specific content goes here -->
  </body>
</html>

Maintaining efficient and reliable script loading

Performance: measurable improvements in First Contentful Paint (FCP) and in Largest Contentful Paint (LCP), thanks to deferred, non-blocking script loading
Standards and maintainability: scripts are delivered as standard <script> elements, generated by Webpack, ensuring consistent behavior across all pages
Best practices: we consistently favor <script> tags with a src attribute over inline JavaScript blocks. This makes scripts cacheable, easier to debug, and aligned with browser parsing rules

By combining native <script> tags and a controlled build-time generation, we ensure predictable execution, page-specific bundles, and a scalable, reliable strategy across all websites.

Managing private TypeScript types: beyond DefinitelyTyped

Yoriiis — Mon, 15 Sep 2025 21:25:41 +0000

TypeScript gives us strong typing and we often rely on DefinitelyTyped for public libraries types. But as soon as you load libraries via a CDN or work on multiple internal projects that don't ship their own types, things start to break down. Each project defines its own version, duplication appears, and TypeScript starts yelling at you.

In large organizations, this often happens: you want all projects to share the same types, but in reality, each team often reinvents its own.

The solution? A centralized internal repository of TypeScript types.

How types propagate: NPM vs CDN

When you install a package from NPM that ships its own types, everything works out of the box. But when you use a library via a CDN, TypeScript can't infer anything. You have to declare the types manually, often by extending Window.

That's when problems appear. One team declares a subset of methods, another team declares slightly different ones. Merge those projects and TypeScript won't know which definition to trust.

Loading a script via a CDN rather than via NPM depends on the use case. Sometimes the script does not exist on NPM, sometimes you want to prioritise a specific execution order.

The problem: conflicting or missing types

Take the example of the following script loaded via a CDN, in this case the Dailymotion Web SDK.

<script defer src="https://geo.dailymotion.com/player.js"></script>

It exposes a global object window.dailymotion. In TypeScript you'd declare it like this according to your requirements:

declare global {
  interface Window {
    dailymotion: {
      createPlayer: (
        selectorId: string,
        options: {
          player: string;
          video: string;
        }
      ) => Promise<{
        on: (event: string, callback: () => void) => void;
        play: () => void;
      }>;
      events: {
        PLAYER_START: string;
        PLAYER_END: string;
      };
    };
  }
}

Now imagine two projects that use the Dailymotion SDK and do not declare exactly the same type. If you merge the two, conflicts will arise. This is often unavoidable because each writes its own version, which may differ.

In the event of a conflict, the following TypeScript error may appear:

error TS2717: Subsequent property declarations must have the same type.

See details of error TS2717 on TypeScript.tv.

Centralizing types: the concept

The solution is to centralize all internal and CDN-related type definitions in a single monorepo. Think of it as your private DefinitelyTyped.

Benefits are immediate:

Consistency: all projects use the same definitions
Reusability: publish once, install everywhere from your private registry
Type safety: no more mismatched types between projects
Maintenance: fix a type once, all consumers get the update

At Prisma Media, we call our monorepo Prime-Types 🤖

Minimal implementation

A minimal monorepo structure could look like this:

package.json  // defines workspaces
types/
  dailymotion/
    package.json
    index.d.ts
    README.md

The root package.json of the monorepo

{
  "name": "types",
  "workspaces": ["./types/*"],
  "scripts": {
    "dev": "tsc --noEmit --watch"
  },
  "devDependencies": {
    "typescript": "5.8.3"
  }
}

Inside types/dailymotion/package.json:

{
  "name": "@prime-types/dailymotion",
  "version": "1.0.0",
  "description": "TypeScript types for Dailymotion",
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "default": "./index.d.ts"
    }
  },
  "main": "./index.d.ts",
  "types": "./index.d.ts",
  "devDependencies": {
    "typescript": "5.8.3"
  }
}

Example type definition for Dailymotion Web SDK in index.d.ts:

// /types/dailymotion/index.d.ts
declare global {
  interface Window {
    dailymotion: {
      createPlayer: (
        selectorId: string,
        options: {
          player: string;
          video: string;
        }
      ) => Promise<{
        on: (event: string, callback: () => void) => void;
        play: () => void;
      }>;
      events: {
        PLAYER_START: string;
        PLAYER_END: string;
      };
    };
  }
}

// Export to ensure the file is treated as a module
export {};

💡 Add export {} at the end of the file if it does not export any types or if only a declare global exists.

To consume these types in a project, install the package in peer-dependencies preferably (see below why in this section).

npm install @prime-types/dailymotion

By default, TypeScript searches for declarations in the node_modules/@types path and in your project source. The rest of node_modules is ignored. You must therefore add the path to your declaration files in the tsconfig.json to allow TypeScript to reference and propagate them.

{
  "include": [
    "./src/**/*",
+   "./node_modules/@prime-types"
  ]
}

👀 Discover this example in the minimalist monorepo Prime Types on GitHub.

Managing multiple versions: peer dependencies

One pitfall may arise: multiple versions of the same type package.

If library A and library B depend on different versions of @prime-types/dailymotion, TypeScript errors may appear.

The solution is to always declare the type package as a peer dependency:

{
  "name": "my-website",
  "peerDependencies": {
    "@prime-types/dailymotion": "1.0.0"
  }
}

That way, only one version can be installed at the top level, and all projects align.

Alternative: a single package

For small teams, you may consider a simplified version: group all types into a single package.

Pros:

Trivial to set up and deploy
Install one package and you're done

Cons:

Harder to version types independently
Package size grows quickly as you add other types

A monorepo with multiple packages is more scalable in the long term.

Conclusion

DefinitelyTyped is ideal for open source, but internal projects sometimes need their own solution. Centralizing TypeScript types has several advantages:

Removes duplication and conflicts
Improves type safety across projects
Gives you a single source of truth

The complete example is available on GitHub for you to try out! 🧑‍💻

Discover Prime Types on GitHub

We have not discussed deployment in this article, but I will detail our deployment workflow with GitLab in a future article.

Automating merge request reviews with Danger on GitLab

Yoriiis — Sun, 03 Aug 2025 22:42:00 +0000

As developers, we spend a lot of time writing code, but also reviewing it, particularly during code review phases between teams.

Sometimes, certain comments are repetitive and could be automated to save developers time. Furthermore, just like unit tests that check our code, we could add tests that check merge requests content (metadata or GIT changes).

This is where Danger comes in. The same tool GitLab itself uses in its open-source projects.

What is Danger

Danger is a tool to automate code review tasks, available on several source code management like GitHub, GitLab or BitBucket.

First, you define rules in a configuration file that run in CI process. Then, when a merge request is created or updated, Danger analyzes the changes and posts comments with warnings or errors into the merge request.

There are two main versions of Danger, Ruby and JavaScript, see Which Danger should I use.

At Prisma Media, we have chosen the Ruby version because it is more mature and stable, and because we wanted to draw inspiration from the configuration files used by the GitLab teams. There is no point in reinventing rules, especially if some of them work within a project as important and global as GitLab.

Danger can perform several types of actions, such as:

Checking changes made to a specific file (GIT changes)
Checking merge request metadata (title, assignee, reviewer, label, etc.)
Using the platform's API directly to extend its scope

See details about Danger reference.

Our Danger rules

To ease adoption, we began by adding a simple rule to every project: checking the CHANGELOG. Because updating the CHANGELOG was sometimes forgotten or incorrectly formatted. A simple, automated rule made this process more reliable and encouraged the use of Danger.

Over time, we added more rules, focusing on recurring feedback that could be automated with Danger.

Here are some examples of the rules we have in place.

Merge request title must contain a Jira ticket
Merge request title should be less than 72 characters
Merge request must have assignees
Merge request must have reviewers if marked as ready
Filenames and directories must not contain uppercase letters or underscores
Changelog must be updated and contain a link to the merge request
Unit tests should be updated if .js, .ts, .tsx files are modified
package-lock.json should be updated if package.json changes

Depending on your requirements, the rules can be a warning or an error if you want the job to fail. Exceptions can also be added, for example if the change is trivial or concerns a part of the code that does not require a new version, the rule is skipped.

We also pay particular attention to the wording of Danger's messages to ensure they are easy to understand.

In addition, if at least one comment has been created, a link allowing Danger to be replayed is displayed. This is very useful if, for example, the feedback concerns metadata from the merge request that can be corrected with just a retry on the job.

At Prisma Media, we call our Danger review bot Alfred.

GitLab CI integration

Create a Dangerfile at the root of the repository. The rule will analyze the metadata of the merge request.

if gitlab.mr_json['title'].length > 72
  warn 'Merge request title should be less than 72 characters.'
end

if gitlab.mr_json['assignees'].empty?
  fail 'Merge request must have assignee(s).'
end

Then, add a job danger-review in the .gitlab-ci.yaml file

danger-review:
  image: ruby:3.3.0
  variables:
    GIT_STRATEGY: fetch
    GIT_DEPTH: 0
  cache:
    key: 'danger-review_ruby-3.3.0_danger-9.5.1_danger-gitlab-8.0.0'
    paths:
      - vendor/bundle
  script:
    - bundle config set --local path 'vendor/ruby'
    - gem install danger --version 9.5.1
    - gem install danger-gitlab --version 8.0.0
    - danger --verbose --fail-on-errors=true --dangerfile=Dangerfile
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

💡 This job uses a versioned GitLab cache for Ruby gems to speed up runs; alternatively, a prebuilt Docker image can be used to avoid repeated installs.

To ensure that Danger has access to your entire GIT repository history, with GitLab it is best to override the settings GIT_STRATEGY and GIT_DEPTH.

The job rules above is important to limit the execution of Danger to merge request pipelines. Because if you run it on a branch pipeline, you could end up in a scenario where the job runs even though the merge request does not yet exist, which would skip the job even though there may be feedback. See details for merge request pipeline.

Authentication

For Danger to comment on merge requests, the pipeline needs a token to perform actions on the merge request.

Create a Project Access Tokens with the API scope, Developer permission, and no expiration date. Add the token as a CI/CD project variable named DANGER_GITLAB_API_TOKEN.

Use CI and Danger as templates

To simplify deployment across multiple projects, CI templates and Danger rules can be hosted in a dedicated repository and imported into consumer projects. This keeps the code centralized and lets it evolve independently.

Create a repository named danger with the following structure:

ci/
  danger-review.yaml
danger/
  changelog
    Dangerfile
    README.md
  metadata/
    Dangerfile
    README.md

Each Danger rule is stored into a dedicated directory with its own documentation.

Transform the danger-review job above into a template CI with variables for personalization.

ci/danger-review.yaml

.danger-review:
  image: ruby:3.3.0
  variables:
    CONFIG_PATH: 'Dangerfile'
    GIT_STRATEGY: fetch
    GIT_DEPTH: 0
  cache:
    key: 'danger-review_ruby-3.3.0_danger-9.5.1_danger-gitlab-8.0.0'
    paths:
      - vendor/bundle
  script:
    - bundle config set --local path 'vendor/ruby'
    - gem install danger --version 9.5.1
    - gem install danger-gitlab --version 8.0.0
    - danger --verbose --fail-on-errors=true --dangerfile=${CONFIG_PATH}
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Create the Danger rules for the changelog.

danger/changelog/Dangerfile

files = (git.added_files + git.modified_files)

if files.include?('CHANGELOG.md')
  diff = git.diff_for_file('CHANGELOG.md')
  unless diff.patch.include?("[##{gitlab.mr_json["iid"]}](#{gitlab.mr_json["web_url"]})")
    fail 'Changelog entry must include the merge request link.'
  end
else
  fail '"CHANGELOG.md" file is missing in GIT diff, version needs to be bump.'
end

Create the Danger rules for the metadata.

danger/metadata/Dangerfile

if gitlab.mr_json['title'].length > 72
  warn 'Merge request title should be less than 72 characters.'
end

if gitlab.mr_json['assignees'].empty?
  fail 'Merge request must have assignee(s).'
end

In a consumer project, import the CI template created above.

.gitlab-ci.yaml

include:
  - { project: 'danger', file: '/ci/danger-review.yaml', ref: 'main' }

danger-review:
  extends: .danger-review

Import the Danger rules into our root Danger file.

Dangerfile

dangerfiles = [
  'changelog',
  'metadata'
]
dangerfiles.each { |file|
  danger.import_dangerfile(
    gitlab: 'danger',
    branch: 'main',
    path: "danger/#{file}/Dangerfile"
  )
}

💡 To simplify version upgrades in the danger repository, use branch names like v1 instead of main. This allows multiple versions, such as v1 and v2, to be maintained in parallel.

Each project can still create specific rules for its own needs by adding them to its local Dangerfile.

Conclusion

Using Danger in CI has dramatically improved merge request quality and consistency across our projects:

Feedback appears directly in merge request threads
Rules are reusable, documented, and shared across multiple projects
Teams spend less time checking trivial issues
Custom project-specific rules are easy to implement

Formulating messages clearly is key. A well-written warning or error guides developers without frustration. With the retry feature and merge request pipelines, the process becomes smooth and almost mandatory.

If your team hasn't tried Danger yet, it's worth exploring. You can start small, automate common rules, and expand gradually to cover project-specific needs.

The complete example is available on GitHub for you to try out! 🧑‍💻

Discover Danger Review on GitHub

Resources

Rebuilding our front-end tech stack for the new teleloisirs.fr

Yoriiis — Sat, 03 Oct 2020 13:12:39 +0000

Getting started

Introduction

Télé-Loisirs is a french TV programs' website with a server-rendered in PHP Symfony. As a front-end engineer, this article covers how we did a progressive rebuild of the website with a new User Interface (UI) and a complete rewrite of the front-end stack. The main goals were to improve page load performances and to facilitate the development of new features with reusable components.

The progressive rebuild

For the UI development, we started with the home page. This page is the main target for our customers and we couldn't change everything in one shot without the risk of losing users. The solution was to rebuild progressively the first page, beginning from the bottom to the top of the page.

This strategy is softer for users, but incredibly more difficult to implement. Indeed, the legacy code needs to cohabit with the new code.

Once all the homepage's components were rebuilt, the clean steps were very important in order to remove all the legacy code and to reorganize the files.

Thinking in components

To build our Design System, all the teams worked together, the UX designers and the front-end and back-end developers. The common goal was to create reusable components all over the site. Throughout the process, we anchored our work around three technical mantras to avoid multiplication of new components:

Does the component already exist?
Can an existing component require only small updates to fit the needs?
Can the design be harmonized?

If any of these questions couldn't be answered positively, we created a new component. It is strict, but was necessary to visually harmonize all our components for our users.

Organize the components

At the beginning we reviewed the mockups of the whole website to identify all the components used by each page. Then we got a list of the components to develop and use-cases.

Components can be specific to a page, shared between a group of pages or shared between all pages. On our site, the groups of pages are related to the sections: program, people, news, amongst others. Each group contains multiple child pages that are free to use either global or group shared components. We added this intermediate level to avoid moving a group shared component to the global level if it wasn't required. The following tree represents our components' structure organization:

# The single page
PAGE_NAME
    # The components of the single page
    COMPONENTS
        COMPONENT_NAME
PAGE_GROUP
    # The child page of the group
    PAGE_NAME
        # The components of the child page
        COMPONENTS
            COMPONENT_NAME
    SHARED
        # The shared components of the group
        COMPONENT_NAME
SHARED
    # The global shared components
    COMPONENT_NAME

This tree structure allows us to organize all components based on where they are used on the website. It makes it easier to manage and use all components either across a page, a group of pages or even the entire website.

Naming the components

For a better understanding of the different components across all teams, we decided to name all of them using a short, simple and descriptive name.

Here are some of the names we use:

navigation
related-news
time-navigation
push-custom-grid
double-broadcast-card

Creating the design variables

We created a file for the global CSS variables. It stores all our graphical charter elements, like:

Colors
Gradients
Shadows
Transition durations
Borders
Fonts
Media Queries

That file is our reference for all the UI and is edited only sparingly to keep the UX harmonized. All the CSS files must use those variables in priority to avoid new additions.

Here is an extract from our global variables file:

:root {
  --containerMaxWidth: 1000px;

  /* Main colors */
  --realBlack: #000;
  --black: #141414;
  --lightBlack: #212121;
  --darkBlue: #696f79;
  --blue: #d5d9e0;
  --grey: #e5e5e5;
  --lightGrey: #f9f9f9;
  --red: #ff004b;
  --white: #fff;
  --placeholderAds: #e3e9f2;

  /* Dark mode */
  --darkmodeRed: #ff236d;
  --darkmodeDarkBlue: #070720;
  --darkmodeBlue: #1c1d42;
  --darkmodeRedGradient: linear-gradient(135deg, #ff236d 0%, #ee5b35 100%);
  --darkmodePlaceholderAds: #151515;

  /* RGBa colors */
  --blackTransparent30: rgba(0, 0, 0, 0.3);
  --blackTransparent80: rgba(0, 0, 0, 0.8);

  /* Gradients */
  --redGradient: linear-gradient(135deg, #ff004b 0%, #ee5b35 100%);
  --purpleGradient: linear-gradient(135deg, #895de4 0%, #cb7995 100%);
  --blackGradient: linear-gradient(180deg, #44474d 0%, #161717 100%);

  /* Shadows */
  --purpleShadow: 0 10px 30px 0 rgba(167, 106, 191, 0.4);
  --greyShadow: 0 10px 30px 0 rgba(229, 229, 229, 0.4);

  /* Transitions */
  --transition300msEase: 0.3s ease;

  /* Border-radius */
  --mainBorderRadius: 15px;

  /* Fonts */
  --font-montserrat: 'Montserrat', sans-serif;
}

/* Media queries */
@custom-media --media-mobile only screen and (max-width: 749px);
@custom-media --media-tablet only screen and (min-width: 750px);
@custom-media --media-desktop only screen and (min-width: 1024px);

Static and dynamic component libraries

In collaboration with the design team, we created two component libraries, one static and one dynamic.

The static component library brings together all the components on Sketch, our design software. There, the components are static and not interactive. It allows us to easily create new pages based on the existing components. New components are automatically added to that library. It is mainly used by the design team and provides a good overview of all the currently available and designed components.

The dynamic component library is created from the static library and brings together all the components in their developed version. It's a tool for the UI development, inspired from StoryBook. In it, components are dynamic, interactive and use the same markup as the ones available on the website: nothing is duplicated. Static data is provided to every component so they can function independently. This library is use by all teams and provides an interactive overview of all the components available on the project.

Optimizing Cumulative Layout Shift

"I was about to click on that! Why did it move? 😭"

Cumulative Layout Shifts can be disturbing for users. It happens when visible elements moves on the page because another element was added, removed or resized in that very same page. We identified the main causes of this behavior on our website:

Images without dimensions
Advertising spaces
Custom web fonts

Placeholders for images

During page load, images are often unavailable and the layout appears differently. Suddenly, elements jump from there to there because images are downloaded and displayed on the page. This is a normal behavior for a web page. In responsive web design, we can't fix the size of the images with the attributes width and height. The solution is to reserve the image area even if it is not yet loaded using the CSS ratio trick.

Imagine the following image inside a container:

<div class="picture">
  <img src="image.jpg" alt="I won't move the page, I promise" />
</div>

Without dimensions, the content below the image will move during the page loads. Because we know the image ratio (calculated by: (height / width) * 100 = ratio), we figured we could prevent that behavior. For example, for a landscape image (16/9), the calculation is: (1080/1920) * 100 = 56.25. The container's height is calculated with the padding ratio, which is responsive (excellent to handle responsive videos by the way). The image is in absolute position, outside of the page flow and fills its container. Thus, having responsive images without layout shifts is possible with this simple technique.

.picture {
  position: relative;
  overflow: hidden;
  height: 0;
  padding-bottom: 56.25%;
}

.picture img {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Placeholders for advertising

We use several formats for advertising which can often result in multiple layout changes on the site. In order to keep fixed advertising areas, we use the previously detailed solution which results in displaying placeholders to reserve areas on the page for the advertising elements. This result in an improved UX. Indeed, textual content and small iconographies can be added to help users easily identify advertising spaces.

Custom web font loading

When a browser requests a font asset from a web server, any elements with styles invoking that font is hidden until the font asset has downloaded. This is known as the “Flash of Invisible Text,” or FOIT.

To avoid these flashes, we use the font-display CSS property. The swap value allows to use the next available system typeface in the font stack for text rendering until the custom font loads. Multiple values are available for different needs.

More information about font-display on CSS Tricks.

Improving web performances

Lighten dependencies

Like most websites, we had a lot of JavaScript dependencies, but now, with all the new ECMAScript features, the game has changed. Native JavaScript is powerful and can easily replace libraries like jQuery.

It's not about reinventing the wheel, but use Javascript native the most possible.

Javascript APIs are used in priority when they are natively supported by the browser. For older browsers, newer features are supported thanks to Polyfill.io.

Loading scripts

Scripts can have a negative impact on the loading time of a page. The location of script tags is important. We used native script tags in the <head> of the document with the defer attribute. That way, scripts will be fetched as soon as possible, but the browser will wait for the DOM tree to be complete before executing them.

More information about scripts loading in the article Efficiently load JavaScript with defer and async.

Content hash

To reduce the number of downloaded files by the browser on each page load, we use the webpack [contenthash] option. Webpack adds a unique hash based on the content of the asset. When the asset's content changes, the [contenthash] changes as well. Files compiled by webpack can remain cached until their content changes. We configured a cache of 1 year for images, JavaScript and CSS files. That way, no matter if another build is deployed to production, the hashes will remain the same for unchanged files and be updated only for edited files. In other words, the first time a user loads the page, all assets will be downloaded and cached by the browser. On the second page load, all unmodified assets will come from the browser's cache even if a new deployment occurred in between both page loads and all modified assets will be downloaded again.

Code-splitting and JavaScript modules

Code size is one of the biggest concerns for an application. Websites often combine all of their JavaScript into a single bundle. When JavaScript is served that way, the page load takes more time because it loads code that is not necessary for the current page. To serve the minimum JavaScript and CSS to the client, we split common JavaScript and CSS code.

In addition, to reduce code size for modern browsers, we introduced Javascript modules using the following approach:

Serve JavaScript modules with ES2015+ syntax for modern browsers (without Babel transpilation).
Serve JavaScript with ES5 syntax for older browsers (with Babel transpilation).

We've detailled a complete codelab on a dedicated article

Yoriiis

May 10 '20

Granular chunks and JavaScript modules for faster page loads

#webdev #webperf #webpack #javascript

Comments

6 min read

Delivering only what the user needs, when he needs it

Today, websites have rich interfaces and display a lot of content. But users still don't see content outside the first screen. So, why would they need to load content they don't see yet? Lazy-loading scripts and contents on scroll can be highly beneficial for performance. We load Javascript bundles that contains only what the user needs and ideally, only what he can see on his screen.

We use the Web API IntersectionObserver to watch when a user is near a target element. For example, all the content below the first screen, which has Javascript dependencies, can be instanciated later. The rootMargin parameter allows us to specify when exactly to trigger elements, according to the user's need. We use a margin of 1 dynamic screen height to trigger the lazy-load like the following example:

const callback = (entries, observer) => {
  console.log('Function is triggered');
};
const options = {
  rootMargin: `0px 0px ${window.innerHeight}px 0px`
};
const observer = new IntersectionObserver(callback, options);

observer.observe(document.querySelector('#footer'));

When the observer detects the target element, a dynamic import is triggered, all assets are loaded and the related JavaScript code is executed.

For browser support, we use the Polyfill.io IntersectionObserver

An open-source version of our observer module is available: lazy-observer on Github

SVG sprites

We use SVG files for icons to avoid HTTP requests and for their flexibility. Additionally, these icons are perfectly displayed no matter the pixel ratio; and animations can be done using CSS. To prevent icons from flickering during the page load, we use SVG sprites. Their content are inlined directly into the HTML. We are using the svg-chunk-webpack-plugin to automate the process of generating each sprites. Each page only imports its own svg sprite which has previously been optimized using svgo.

Responsive images

Users' screens are all different by sizes (watches, phones, tablets, laptops, desktops) and by pixel density (1x, 2x, 3x). Pictures made for a 1x pixel density can appear pixelated on devices with higher pixel density. Nomad devices generally have a slower connection. To provide the most suitable image format for any user, we need responsive images.

For images with the same ratio for all different breakpoints, the <img> tag, along with the srcset and size attributes are enough. For more complex use cases, the <picture> tag can be used, but it has the disadvantage of increasing the DOM size.

The following example displays an image that is compatible with different screen sizes, all formats (mobile, tablet and desktop), plus, the 1x and 2x pixel density.

<img
  src="image-64x90.jpg"
  sizes="(max-width: 750px) 64px, (max-width: 1023px) 64px, (min-width: 1024px) 64px"
  srcset="image-64x90.jpg 64w, image-128x180.jpg 128w"
  alt="My responsive image"
/>

Better accessibility

Accessibility is essential on websites. It provides a better experience for all users. We use tools like Google Lighthouse to generate analysis reports, they contain useful information to improve it.

Some rules can greatly improve the score:

Use a minimum size for all links and buttons, along the padding property
Use <h1|2|3|4|5|6> for titles
Use <ul> or <ol> for lists
Use the <a> for link and the <button> for elements with Javascript action
Add the alt attribute on images
Add the title attribute on links
Add the aria-label attribute on <button|a> without text
Adjust the contrast for the color of the design
Respect HTML descendants (ul>li)

CSS tips for semantic

Monitoring

To monitor performance, we use two different tools:

SpeedCurve to analyze daily several of our main pages. This allows us to detect different types of issues:

Page load duration
Page size
Assets size
Number of requests
Lighthouse score

Google Page Speed Insights for occasional reports.

Rethinking CSS

CSS naming conventions

To improve maintainability and performance, we use a CSS naming convention: the flat hierarchy of selectors, inspired from BEM (Block Element Modifier) and FUN. CSS selectors are unique and shorter, which leads to smaller CSS files. To avoid class names that become too long quickly, we keep modifier classes independent from the block class name. In addition, the block class name and the element class name use the camelCase syntax with an hyphen as separator.

.blockName-elementName .modifier {
}

CSS variables for theming (dark mode)

The dark mode applies a custom theme to the website. It works by adding a class name to the <html> element. Our first approach was to override existing styles with rules that had higher specificities. We quickly noticed that this approach had issues. One of them being a considerable increase of the size of CSS files.

We've switched to native CSS variables for theming. That way the size of our CSS files remains lighter even if they contain both light and dark mode styles. Below, an example of the background color of an header element being overridden by another color when the dark mode is enabled.

.darkMode .header {
  --backgroundColor: #1c1d42;
}

.header {
  --backgroundColor: #212121;
  background-color: var(--backgroundColor);
}

Support for IE11 had to be dropped to use native CSS variables and keep small CSS files. Otherwise the generated file would have duplicated all the CSS rules.

Code review

Team work are important part of our development processes. Code reviews helps improving the maintainability of a project, team spirit and allow everyone to increase theirs skills. To make the code review easier, merge requests needs to be small and their context needs to be respected. Merge requests are kept small which leads to a more efficient review.

Some of the rules we follow are listed in an article (in French) by @Julien Hatzig:

Promote asynchronous reviews.
Avoid making the review synchronous by asking for validation, but rather ask for a review of your work. This will put the reviewer in a better position which will leads to constructive feedback.
Add a context with a description in the header of the merge request. The reviewer doesn't know the topic you worked on.
Take the time to review other people's code.
Be benevolent in exchanges, favor the conditional in sentences, suggest solutions, describe problems.
Avoid sniper reviews.
Comments are not negative for the developer, they stimulate discussion and lead to improvements. Discuss more when necessary to find the most suitable solution.

Additional reading

Cumulative Layout Shift

Granular chunks and JavaScript modules for faster page loads

Yoriiis — Sun, 10 May 2020 09:37:07 +0000

The race to performance increases from year to year and the front-end ecosystem is evolving more than never.

This article covers how to build a Webpack configuration to improve page load performance. Learn how to set up a granular chunking strategy to split common code. Then, serve modern code with JavaScript modules to modern browsers.

Webpack configuration

To start, the configuration has the following features:

Multiple Page Application
Development and production environment
JavaScript transpilation with Babel and preset-env
CSS extraction
Default optimization behavior

First, let's write our Webpack starter configuration.

webpack.config.js

const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

// Export a function for environment flexibility
module.exports = (env, argv) => {
  // Webpack mode from the npm script
  const isProduction = argv.mode === 'production';

  return {
    watch: !isProduction,

    // Object entry for Multiple Page Application
    entry: {
      home: 'home.js',
      news: 'news.js'
    },

    output: {
      path: path.resolve(__dirname, './dist'),
      filename: '[name].js'
    },

    module: {
      rules: [
        // Babel transpilation for JavaScript files
        {
          test: /\.js$/,
          loader: 'babel-loader',
          options: {
            presets: [
              [
                '@babel/preset-env',
                {
                  targets: {
                    browsers: ['last 2 versions']
                  },
                  // Include polyfills from core-js package
                  useBuiltIns: 'usage',
                  corejs: 3
                }
              ]
            ]
          }
        },

        // Extract content for CSS files
        {
          test: /\.css$/i,
          use: [MiniCssExtractPlugin.loader, 'css-loader']
        }
      ]
    },

    resolve: {
      extensions: ['.js', '.css']
    },

    plugins: [
      // Configure CSS extraction
      new MiniCssExtractPlugin({
        filename: '[name].css',
        chunkFilename: '[name].css'
      })
    ],

    // Default optimization behavior depending on environment
    optimization: {
      minimize: isProduction
    }
  };
};

For more flexibility, the configuration exports a function, but other configuration types are available.

The entry key is an object to accept multiple entries (Multiple Page Application). Each entry contains the code for a specific page of the site (ex: home, news, etc.).

The module.rules key is an array with two rules, one for the JavaScript files and one for the CSS files.

The babel-loader is used to transpile JavaScript with the presets from @babel/preset-env.

💡 Browsers list
The last 2 versions transpiles the code for the last two versions of every browsers. It's not the best option, choose instead a browsers list to match your real audience.

The css-loader is used to interpret CSS files and MiniCssExtractPlugin to extract CSS content in a dedicated file.

The plugins array has a unique plugin MiniCssExtractPlugin to extract CSS content.

The optimization object has the default behavior; the minimize option depends of the Webpack mode (development or production).

💡 Minimizer
The minimize key can be replaced by minimizer to perform optimization with TerserPlugin.

Let's add the npm scripts that will start and build Webpack:

package.json

{
  "start": "webpack --mode=development",
  "build": "webpack --mode=production"
}

Granular chunks

Split common code

Webpack splitChunks allows to split common code used inside all entrypoints.

This generates one entrypoint file for JavaScript and CSS plus multiple chunk files which contain common code.

Imagine the pages share some common code for the header. Without the optimization, common code is duplicated across every entrypoints.

With the optimization, a chunk is automatically created with the shared code.

To use this option with multiple entrypoints, the easiest is to install the chunks-webpack-plugin.

npm install chunks-webpack-plugin --save-dev

Then, update the Webpack configuration to add the plugin.

const ChunksWebpackPlugin = require('chunks-webpack-plugin');

module.exports = (env, argv) => {
  return {
    // ...
    plugins: [
      new ChunksWebpackPlugin({
        filename: 'templates/[name]-[type].html.twig',
        templateStyle: (name) => `<link rel="stylesheet" href="${name}" />`,
        templateScript: (name, entryName) => `<script defer src="${name}"></script>`
      })
    ]
  };
};

Enable the optimization.splitChunks to target all type of chunks.

module.exports = (env, argv) => {
  return {
    // ...
    optimization: {
      splitChunks: {
        chunks: 'all'
      }
    }
  };
};

💡 Build performance
Enable splitChunks only for production. I strongly advise you to enable the name option for debugging.

That's all, granular chunking is done, no more configuration 🎉

Include chunk templates

Now that everything is set up, include the generated templates in the page templates.

With a multiple page application, a base layout is commonly used and pages override blocks. The layout defines the blocks. The pages includes specific files inside these blocks.

base.html.twig

<!DOCTYPE html>
<html>
  <head>
    {% block styles %}{% endblock %}
    {% block scripts %}{% endblock %}
  </head>
  <body>
    {% block body %}
      {# Application code here #}
    {% endblock %}
  </body>
</html>

home.html.twig

{% extends 'base.html.twig' %}

{% block styles %}
  {{ include 'dist/templates/home-styles.html.twig' }}
{% endblock %}

{% block body %}{% endblock %}

{% block scripts %}
  {{ include 'dist/templates/home-script.html.twig' }}
{% endblock %}

news.html.twig

{% extends 'base.html.twig' %}

{% block styles %}
  {{ include 'dist/templates/news-styles.html.twig' }}
{% endblock %}

{% block body %}{% endblock %}

{% block scripts %}
  {{ include 'dist/templates/news-script.html.twig' }}
{% endblock %}

Content of these generated templates will looks like this:

home-styles.html.twig

<link rel="stylesheet" href="dist/vendors~home~news.css" />
<link rel="stylesheet" href="dist/home.css" />

home-scripts.html.twig

<script src="dist/vendors~home~news.js"></script>
<script src="dist/home.js"></script>

Script type module & nomodule

Many polyfills are not needed for modern browsers. By using modules, Babel transpilation can be avoided and bundle sizes are reduced.

HTML provides useful attributes for the <script> tag to detect modern browsers and JavaScript modules' support.

`<script type="module">`

Serve JavaScript modules with ES2015+ syntax for modern browsers (without Babel transpilation).

<script src="dist/modern/home.js" type="module"></script>

`<script nomodule>`

Serve JavaScript with ES5 syntax for older browsers (with Babel transpilation).

<script src="dist/legacy/home.js" nomodule></script>

Browsers support

Browsers that support modules ignore scripts with the nomodule attribute. And vice versa, browsers that do not support modules ignore scripts with the type="module" attribute.

This feature is supported by all latest versions of modern browsers, see on Can I use.

⚠️ Bad guys
IE 11 and Safari 10 are a problematic and download both bundles. Discussion is in progress to fix it on Safari, see the Github Gist.

Multiple Webpack configurations

Instead of exporting a single Webpack configuration, you may export multiple configurations. Simply wrap the different object configurations inside an array.

Let's create a function to avoid code duplication between our configurations.

config-generator.js

const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const ChunksWebpackPlugin = require('chunks-webpack-plugin');

const configGenerator = ({ browsers, isProduction, presets }) => {
  // Custom attribute depending the browsers
  const scriptAttribute = browsers === 'modern' ? 'type="module"' : 'nomodule';

  return {
    // The name of the configuration
    name: browsers,

    watch: !isProduction,
    entry: {
      home: 'home.js',
      news: 'news.js'
    },
    output: {
      path: path.resolve(__dirname, `./dist/${browsers}`),
      filename: '[name].js'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          loader: 'babel-loader',
          options: {
            // Presets depending the browsers
            presets
          }
        },
        {
          test: /\.css$/i,
          use: [MiniCssExtractPlugin.loader, 'css-loader']
        }
      ]
    },
    resolve: {
      extensions: ['.js', '.css']
    },
    plugins: [
      new MiniCssExtractPlugin({
        filename: '[name].css',
        chunkFilename: '[name].css'
      }),
      new ChunksWebpackPlugin({
        filename: 'templates/[name]-[type].html.twig',
        templateStyle: (name) => `<link rel="stylesheet" href="${name}" />`,
        templateScript: (name, entryName) => {
          if (type === 'modern') {
            return `<script type="module" src="${name}"></script>`;
          }
          return `<script nomodule defer src="${name}"></script>`;
        }
      })
    ],
    optimization: {
      splitChunks: {
        chunks: 'all'
      }
    }
  };
};

Next, the webpack.config.js needs to export two configuration with the configGenerator function. The first for modern browsers and the second for legacy browsers, with the different Babel presets. The presets target esmodules browsers instead of a browsers list.

webpack.config.js

import configGenerator from './config-generator';

module.exports = (env, argv) => {
  const isProduction = argv.mode === 'production';

  // Modern browsers that support Javascript modules
  const configModern = configGenerator({
    browsers: 'modern',
    isProduction,
    presets: [
      [
        '@babel/preset-env',
        {
          targets: {
            esmodules: true
          }
        }
      ]
    ]
  });

  // Legacy browsers that do not support Javascript modules
  const configLegacy = configGenerator({
    browsers: 'legacy',
    isProduction,
    presets: [
      [
        '@babel/preset-env',
        {
          targets: {
            esmodules: false
          },
          useBuiltIns: 'usage',
          corejs: 3
        }
      ]
    ]
  });

  return [configModern, configLegacy];
};

When running Webpack, all configurations are built.

💡 Run a specific configuration
Add --config-name=<BROWSERS> at the end of the npm script. Replace <BROWSERS> by the name of the Webpack configuration (modern or legacy in the example above).

Update chunk templates

Include both bundles for JavaScript to target modern and legacy browsers. For CSS, the configuration is identical for both browsers, you can import one or the other.

home.html.twig

{% extends 'base.html.twig' %}

{% block styles %}
  {{ include 'dist/templates/modern/home-styles.html.twig' }}
{% endblock %}

{% block body %}{% endblock %}

{% block scripts %}
  {{ include 'dist/templates/modern/home-script.html.twig' }}
  {{ include 'dist/templates/legacy/home-script.html.twig' }}
{% endblock %}

news.html.twig

{% extends 'base.html.twig' %}

{% block styles %}
  {{ include 'dist/templates/modern/news-styles.html.twig' }}
{% endblock %}

{% block body %}{% endblock %}

{% block scripts %}
  {{ include 'dist/templates/modern/news-script.html.twig' }}
  {{ include 'dist/templates/legacy/news-script.html.twig' }}
{% endblock %}

Conclusion

You now understand how to customize the Webpack configuration to improve page load performance.

Granular chunks with Webpack and chunks-webpack-plugin offer a better strategy to shares common code.

Next, JavaScript modules provide minimal polyfills and smaller bundles for modern browsers.

The complete example is available on GitHub for you to try out! 🧑‍💻

Discover Webpack splitChunks ESModule on GitHub

Additional reading

Photo by @dylan_nolte on Unsplash
With thanks to Emilie Gervais for her review

The real power of Webpack 4 SplitChunks Plugin

Yoriiis — Thu, 01 Aug 2019 21:26:00 +0000

This article was originally published on Medium and has been slightly updated for Dev.to.

If you have read Hemal Patel's excellent article about the Mysterious SplitChunks Plugin, you probably asked yourself the same question as I did.

How do I include the code splitting optimization splitChunks.chunks "all", into my project?

SplitChunks finds modules which are shared between chunks and splits them into separate chunks to reduce duplication or separate vendor modules from application modules.

SplitChunks accepts 3 possible values initial, async or all.

According to the Webpack documentation:

"Providing all can be particularly powerful, because it means that chunks can be shared even between async and non-async chunks"

Hemal Patel explains it differently:

"Hey, webpack! I don't care if it is a dynamically imported module or non-dynamically imported module. Apply optimization over all of them. But make sure that… naah, you are smart enough to do that!"

The difference between Entry Points and Chunks

Entry Points

The point(s) to enter the application. Here the application starts executing. If an array is passed all items will be executed.

A dynamically loaded module is not an entry point.

Simple rule: one entry point per HTML page. SPA: one entry point. MPA: multiple entry points (this, according to the Webpack documentation).

Example of entry points in a multiple page application

module.exports = {
  //...
  entry: {
    home: './home.js',
    about: './about.js',
    contact: './contact.js'
  }
};

Chunks

"Chunk" is a Webpack specific term that is used internally to manage the bundling process. Webpack composes bundles out of chunks. Chunks are automatically generated by Webpack from a list of entry points.

Webpack configuration

When you include this optimization into your Webpack configuration, it must look like this:

module.exports = {
  //...
  optimization: {
    splitChunks: {
      chunks: 'all'
      name: false
    }
  }
};

The name parameter corresponds to the name of the split chunks. Providing true will automatically generate a name based on chunks and cache group key. I strongly advise you to enable this option for debugging during development only.

Now, Webpack will automatically analyze shared code and dependencies between your files (CSS and Javascript) and will generate new chunks associated with these entry points.

The question is now:

What is the link between an entry point and its corresponding chunk(s)?

The plugin HtmlWebpackPlugin generates HTML files with entry points, but without chunks. Also, this plugin is not appropriate for a multiple page application, it requires an instantiation per entry point and this is not optimal for build performance.

After days of searching the Internet for the best solution to integrate code splitting optimization into my project, I finally decided to code my own plugin.

Install ChunksWebpackPlugin

The chunks-webpack-plugin creates HTML files to serve your Webpack bundles. It is very convenient for multiple entry points and works without configuration for basic usage. For more complex usage, there are hooks available for more flexibility.

All the documentation is available on Github and npm.

npm install --save-dev chunks-webpack-plugin

Includes assets in your templates

Include each HTML file on the corresponding page like the example below:

<!DOCTYPE html>
<html>
  <head>
    <?php include 'home-styles.html'; ?>
  </head>
  <body>
    <?php include 'home-scripts.html'; ?>
  </body>
</html>

You are free to change many of the options including the path, the name, the language and the content of the output files. This example is in PHP, but it works with TWIG and all others languages.

Generated HTML files contain script and style tags with the ordered list of all chunks associated with the entry point plus the entry point itself.

Example of the content of the file home-styles.html:

<link rel="stylesheet" href=".styles/0.cfcccdf4f79b40e.css" />
<link rel="stylesheet" href=".styles/home.cfcccdf4f79b40e.css" />

Example of the content of the file home-scripts.html:

<script defer src="./scripts/1.cfcccdf4f79b40e.js"></script>
<script defer src="./scripts/0.cfcccdf4f79b40e.js"></script>
<script defer src="./scripts/home.cfcccdf4f79b40e.js"></script>

Debug with WebpackBundleAnalyzer

Use the package WebpackBundleAnalyzer to understand how your code is being split.

In conclusion,

I have integrated code splitting with the plugin chunks-webpack-plugin into several projects, including the website Télé-Loisirs, and I am very pleased with the result!

Many thanks to Webpack team for the awesome documentation and to various discussions and blog posts from the community, I could not have done this without it.

DEV Community: Yoriiis

Why I built vLitejs, a fast and flexible native video and audio player

History

Context and motivation

Design principles and architecture

Features

How it works

Initializing the player

Providers example (YouTube)

Plugins example (PIP + subtitle)

Global events

Creating a custom plugin

What's next

Key takeaways

Conclusion

Resources

From ESLint/StyleLint and Prettier to Biome: simplifying our front-end linting

Challenges with ESLint, StyleLint and Prettier

Migration to Biome

Biome in CI/CD

ESLint vs Biome — simplified comparison

Key notes

Improving accessibility for popins: focus trap and keyboard handling

Conclusion

Resources

Improving accessibility for popins: focus trap and keyboard handling

The problem

Implementation

Initial focus on the close button

Trap focus inside the popin

Visible focus styling

Example

HTML

CSS

JavaScript

Key points

Conclusion

Resources

How we test NPM packages before publishing with npm pack

Understanding npm pack

Testing options

Implementation

Scaling GitLab CI/CD with reusable templates

GitLab CI template

Advantages

Key points

Conclusion

Resources

Scaling GitLab CI/CD with reusable templates

Why a dedicated CI templates repository

The problem: scattered CI configurations

Our solution: modular templates

Our template catalog

Pipeline overview

Shared configuration

Selected CI templates

npm-install: install dependencies

npm-build: build application

npm-qa: run linter (Biome)

npm-unit-test: run unit tests (Jest)

npm-pack: generate local package

npm-publish: publish to NPM registry

create-tag: create Git tag

Final consumer usage

Versioning and evolution

Results and lessons learned

Conclusion

Resources

Efficient script loading strategy

Before 🦖: a JavaScript loader to control execution

Back to basics

Handling our loading sequence

Granular chunks and JavaScript modules for faster page loads

💡 Key notes:

HTML rendering

Maintaining efficient and reliable script loading

Managing private TypeScript types: beyond DefinitelyTyped

How types propagate: NPM vs CDN

The problem: conflicting or missing types

Centralizing types: the concept

Understanding `npm pack`

`npm-install`: install dependencies

`npm-build`: build application

`npm-qa`: run linter (Biome)

`npm-unit-test`: run unit tests (Jest)

`npm-pack`: generate local package

`npm-publish`: publish to NPM registry

`create-tag`: create Git tag

`<script type="module">`

`<script nomodule>`