Forem: Alessandro Rabitti

Renovate in Gitlab pipeline

Alessandro Rabitti — Sat, 01 Mar 2025 16:01:58 +0000

Consider Renovate an automation for dependencies upgrade, that creates Merge Requests in your project.

These are the steps I followed to enable it a the project, within Gitlab pipeline.

Create Gitlab Token (Project or Personal, it will set the creator of your Merge Requests) for Renovate to have access to you repository
Add the Gitlab Token to the Env variables of the project, to allow the token to be provided to the pipeline in the gitlab-ci.yml file
Create a configuration file renovate.json in the root folder of your project as the following, this is an example for npm package manager, check the suitable for your type of project.

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "commitMessageExtra": "from {{currentVersion}} to {{newVersion}}",
    "commitMessagePrefix": "Upgraded",
    "commitMessageTopic": "{{depName}}",
    "enabledManagers": ["npm"],
    "minimumReleaseAge": "3 days",
    "packageFiles": ["package.json"],
    "packageRules": [
        {
            "addLabels": ["libs"],
            "automerge": false,
            "commitMessageAction": "patch for",
            "matchUpdateTypes": ["patch"]
        },
        {
            "addLabels": ["libs"],
            "automerge": false,
            "commitMessageAction": "minor for",
            "matchUpdateTypes": ["minor"]
        },
        {
            "addLabels": ["libs"],
            "automerge": false,
            "commitMessageAction": "major for",
            "matchUpdateTypes": ["major"]
        }
    ],
    "prBodyColumns": ["Package", "Package file", "Type", "Update", "Change", "Pending", "References"],
    "prConcurrentLimit": 10,
    "prHourlyLimit": 3,
    "reviewersFromCodeOwners": true,
    "timezone": "Europe/Amsterdam"
}

For more information https://docs.renovatebot.com/configuration-options/

Configure renovate in the gitlab-ci.yml file, this is an example setting up a scheduled and manual trigger.

stages:
  - renovate

variables:
  RENOVATE_BASE_DIR: .
  RENOVATE_ENDPOINT: $CI_API_V4_URL
  RENOVATE_PLATFORM: gitlab
  RENOVATE_TOKEN: $GITLAB_PROJECT_RENOVATE_TOKEN
  RENOVATE_GIT_AUTHOR: "Renovate Bot <bot@renovateapp.com>"
  LOG_FILE: renovate-log.ndjson
  LOG_FILE_LEVEL: debug
  RENOVATE_REPOSITORIES: "$CI_PROJECT_PATH"
  RENOVATE_AUTODISCOVER: false

renovate:
  image:
    name: ghcr.io/renovatebot/renovate:39
    pull_policy: always
  script:
    - renovate $RENOVATE_EXTRA_FLAGS
  stage: renovate
  resource_group: production
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $RENOVATE_JOB == "1"
      when: always
    - if: $CI_PIPELINE_SOURCE == "web" && $RENOVATE_JOB == "1"
      when: manual
  artifacts:
    when: always
    expire_in: 3d
    paths:
      - '$LOG_FILE'

Create a scheduled pipeline in through the section Build → Pipeline schedules menu, setting up a variable RENOVATE_JOB to allow just this pipeline to be triggered.

Notes

Every year the GitLab token expires, so it is required to generate a new one and reset it in the project Env variables.

This example renovate.json can be suitable for nodejs projects, check how to replace these two fields for other type of project,

    "enabledManagers": ["npm"],
    "packageFiles": ["package.json"],

depending on the type of module package.

To ignore dependencies use this field:

    "ignoreDeps": ["react"]

To ignore certain type of versions use this field:

    "packageRules": [{
      "matchUpdateTypes": ["major"],
      "enabled": false
    }]

Good automations.

How to add a radial gradient around the mouse cursor on the background of a page in Vue.js

Alessandro Rabitti — Mon, 02 Dec 2024 20:19:59 +0000

In order to spice up a website, I decide to implement a radial gradient that shines around the cursor, on every mouse movement along the screen view. The following implementation is adapted to a Vue.js project built with TypeScript.

In order to achieve this result, I also want to use, for simplicity, a library for device detection, and my choice goes to ua-parser-js, precisely the version 2.0.0.

The second and coral step is the creation of a gradient component, that must be the main container of all the view, since it will be the area where the gradient will be shining.

// src/components/Gradient.vue

<script lang="ts">
import { computed, ref, onMounted, onUnmounted } from 'vue'
import { isMobile } from '../utils/device'

export default {
  name: 'GradientView',
  setup() {
    const getViewCentrePosition = () => ({
      x: window.innerWidth / 2,
      y: window.innerHeight / 2
    })

    const cursorPositionRef = ref(getViewCentrePosition())

    const updateCursorPosition = (event: MouseEvent) => {
      if (!isMobile()) {
        cursorPositionRef.value = {
          x: event.clientX,
          y: event.clientY
        }
      }
    }

    onMounted(() => {
      if (!isMobile()) {
        window.addEventListener('mousemove', updateCursorPosition)
      }
    })

    onUnmounted(() => {
      if (!isMobile()) {
        window.removeEventListener('mousemove', updateCursorPosition)
      }
    })

    const gradientPosition = computed(() => {
      return `${cursorPositionRef.value.x}px ${cursorPositionRef.value.y}px`
    })

    return {
      gradientPosition
    }
  },
  data() {
    return {
      isMobileClass: isMobile()
    }
  }
}
</script>

<template>
  <div
    :class="{ 'gradient--desktop': !isMobileClass, gradient: true }"
    :style="{ '--gradient-position': gradientPosition }"
  >
    <slot />
  </div>
</template>

<style scoped lang="scss">
div {
  .gradient.gradient--desktop {
    background-image: radial-gradient(
      circle at var(--gradient-position, 50% 50%),
      var(--tertiary-color),
      var(--secondary-color) 20%
    );
    width: 100vw;
    height: 100vh;
    overflow: scroll;

    @media (prefers-color-scheme: dark) {
      background-image: radial-gradient(
        circle at var(--gradient-position, 50% 50%),
        var(--tertiary-color),
        var(--primary-color) 20%
      );
    }
  }
}
</style>

Let's understand the code. In the script section I have a function that simply returns the initial position, the centre of the screen view. It could be handled differently, for example hidden, or on the top left position that can appear with an animation after the first mouse trigger. It is an implementation choice. For simplicity I add it at the centre of the view.

const getViewCentrePosition = () => ({
  x: window.innerWidth / 2,
  y: window.innerHeight / 2
})

Then I create a reactive reference to the object that will be in use to track cursor mouse movements, occurring through the mouse events.

const cursorPositionRef = ref(getViewCentrePosition())

Then I implement the function that is in charge of updating the reactive reference object, after every cursor mouse movement.

const updateCursorPosition = (event: MouseEvent) => {
  if (!isMobile()) {
    cursorPositionRef.value = {
      x: event.clientX,
      y: event.clientY
    }
  }
}

This function needs to be associated to the mouse events.

onMounted(() => {
  if (!isMobile()) {
    window.addEventListener('mousemove', updateCursorPosition)
  }
})

onUnmounted(() => {
  if (!isMobile()) {
    window.removeEventListener('mousemove', updateCursorPosition)
  }
})

And finally I compute the reactive value of the gradient position, that will be provided to the css of the element itself.

const gradientPosition = computed(() => {
  return `${cursorPositionRef.value.x}px ${cursorPositionRef.value.y}px`
})

Note that in most of the parts above described, I do make a check if the detected device is on mobile or not, to avoid useless computations where unnecessary.

Afterwards in the template I create the html of the gradient, that behaves as a full page wrapper for the content, and I also apply the relative css, only if needed.

<template>
  <div
    :class="{ 'gradient--desktop': !isMobileClass, gradient: true }"
    :style="{ '--gradient-position': gradientPosition }"
  >
    <slot />
  </div>
</template>

And this is the css. I offer here a solution for a website that implements light and dark theme, and I make use of two colors for the transition, on the external part I use --primary-color and --secondary-color colors, while the internal part is setup for both themes as --tertiary-color. But, choice and tuning, is yours.

<style scoped lang="scss">
.gradient.gradient--desktop {
  background-image: radial-gradient(
    circle at var(--gradient-position, 50% 50%),
    var(--tertiary-color),
    var(--secondary-color) 20%
  );
  width: 100vw;
  height: 100vh;
  overflow: scroll;

  @media (prefers-color-scheme: dark) {
    background-image: radial-gradient(
      circle at var(--gradient-position, 50% 50%),
      var(--tertiary-color),
      var(--primary-color) 20%
    );
  }
}
</style>

At last, this is the only utility in use, as previously mentioned, to detect the device.

// src/utils/device.ts

import { UAParser } from 'ua-parser-js'

export const isMobile = (): boolean => {
  const uap = new UAParser()
  return uap.getDevice().type === 'mobile'
}

Better ideas? Curious to hear them.

Design Systems, Design Tokens and the eternal battle between efficiency and flexibility

Alessandro Rabitti — Thu, 28 Nov 2024 21:26:13 +0000

From an old article: https://medium.com/@silversonicaxel/design-systems-design-tokens-and-the-eternal-battle-between-efficiency-and-flexibility-1feaaaf987c7

It’s 2021.

It’s been seven years since the concept of Design System was concretely defined by Google with its Material Design in 2014.

And it’s five years since Design Tokens made their first official appearance due to a great idea that became implementation from Salesforce people within their Lightning in 2016.

If you would like to know more about Design System, here is an interesting link on the internet https://www.invisionapp.com/inside-design/guide-to-design-systems/.

You are very familiar with the Design System concept but you feel a newbie regarding Design Tokens, take a tour here https://www.invisionapp.com/inside-design/design-tokens/ and if you have 40 minutes more, watch this awesome presentation https://www.youtube.com/watch?v=wDBEc3dJJV8.

You might be aware of the main reasons why Design Systems and Design Tokens are important nowadays, such as Unique source of truth, Scalability, Maintainability or Theming.

As well, you might be also aware that the internet is already full of great examples, tutorials, opinions, suggestions to highlight the best approaches to implement a great Design System with a great Design Tokens setup.

Within this evolution and exposure, the trend is becoming more and more popular across big companies that are implementing their own systems and share them to the world. Why so? It’s a signature, it’s the identity and personality and it helps in efficiency and flexibility.

But the question is, which is the best approach if we are searching for efficiency and flexibility?

It’s a constant challenge indeed between design and development, between web and mobile, between reusability and exception, between flexibility and efficiency. It is a to-be or not-to-be matter.

The common goal is to share as much as possible in terms of reusability. Specially if the Design System we are working on is supposed to serve multiple themes. The less Design Tokens you define, the more your Design System is maintainable and we achieve efficiency.

The more Design Tokens you need, the more your Design System is customisable and we achieve flexibility.

The balance between identical multi themes and different multi themes resides in this, the ability of creating a proper design tokens structure, that let you be different and faster.

How to work on a multi theme Design System?

From a theoretical point of view it is very simple. It is just necessary to define a list of all the Design Tokens necessary to implement from a development point of view all the design decisions and reuse them across all the layouts of the Design System, for all the provided themes. Easy right?

When we leave the theory and face the practice, things might become more complicated. How come?

We have design and development for desktop applications and native applications.
We have one unique Design System that is used for multiple themes and some differences are strictly necessary.
We have to take into account the default implementation mode but we have to manage also the dark mode.
We have to consider that Design Tokens might require different types of output accordingly to the amount of tools that the consumers are using.
We have the requirement of creating a new theme in a day. And the list can grow.

Let’s try to focus on some questions we are going to ask ourselves along the way.

Do I need some specific decision, tokenisable in the same way for all themes, that can’t be applied with a current design token?

Create a new token, but that will have a cost in terms of maintainability because it takes more time to maintain more Design Tokens during the creation or the update of a theme.

Do I need some specific decision, diverging from the default behaviour but just for one or few specific themes?

Create a new exception token, but that will have cost in terms of reusability, because you might end up to have more Design Tokens not shared across all themes of your Design System.

Avoid diverging and make a compromise following an already defined design decision, that has a cost in terms of flexibility, because a design decision should be tuned to be aligned with the different default layout of your Design System.

So what is the best answer?

Taking these types of decisions it makes you feel like in an attempt of moving a “node of a web”. It becomes pretty visible under your eyes that with any little movement, everything moves.
So what is the best answer? There is no best answer. Every Design System has its own answer.
Or we can assert that the challenge to achieve the best answer can’t be too far from a good balance. Otherwise the “web” is going to break somewhere.

Designers and developers should become best friends and cooperate strictly with each others taking into account the deep meaning of every Design Token of the Design System, thinking of all the good and bad consequences that every decision has, understanding the impact of any new token creation or of an existing token update, measuring efforts in this balanced challenge.

An example can help

Let’s analyse few lines of code to understand what is the good balance between.

❌ a too efficient oriented approach — super easy to maintain but difficult to customise

$color-text: 'black';

❌ a too flexible oriented approach — super easy to customise but difficult to maintain

$color-text: 'black';
$color-text-label-small: 'midnightblue';
$color-text-label-medium: 'indigo';
$color-text-label-large: 'navy';
$color-text-error-input: 'red';
$color-text-error-textarea: 'darkred';
$color-text-error-fileuploader: 'firebrick';
$color-text-error-checkbox: 'maroon';
$color-text-error-radio: 'tomato';
$color-text-error-image: 'orangered';

✅ a balanced approach — compromised and easy to maintain and customise

$color-text: 'black';
$color-text-label: 'navy';
$color-text-error: 'maroon';

The only way is to try it out.
So enjoy the challenge and have a good balance!