Due to an update to the ESLint extension, the settings schema has changed.
ESLint attempts to change them to the new options as soon as it detects the old ones. We set our desired behaviour
(by default to do all the heavy lifting for us), so nobody else commits incorrect settings by accident or
uses the incorrect behaviour
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
Vuetify was updated to support it and we no longer use vite-plugin-pages
and vite-plugin-vue-layouts
which previously were our blockers
Signed-off-by: GitHub <noreply@github.com>
armhf/armv7+ architecture is being dropped these days by a multitude
of other applications in favor of arm64
We kept it because, back at the time, Raspberry Pi OS 64 was really new
and there wasn't a widespread support of the architecture in that specific SBC
family. This is no longer the case, so the importance
to keep it just for the sake of backwards compatibility is really low.
It's not the first time since arm has posed some challenges after the introduction
of lightningcss. We could always deprecate it (being it's Vite support experimental)
but the possibility to automatically have the best CSS compatibility just by using browserslists
is a really huge advantage over the old PostCSS/esbuild setup.
Plus the resulting CSS it's smaller in size.
Upstream doesn't want to really support the platform either (and they're somewhat right): https://github.com/parcel-bundler/lightningcss/issues/563
Signed-off-by: GitHub <noreply@github.com>
* There's already an nginx user in the container
* Join chowns into a single statement
* Remove ``--ignore-scripts``, in an attempt to fix arm (unsuccessfully)
The chances of exploting ignore scripts (initially proposed by SonarCloud) is really low:
* It runs into a container
* The container is 99% of the times built in GiHub Actions environment.
It also introduces a mismatch between lint and typecheck commands and most dev environments (not everyone runs npm with that flag enabled).
In Vite 4, a simple regex was used to replace the variable,
which would lead to undefined at runtime.
That commit was a temporary fix until Vite 5 landed in stable, since supposedly it would
improved upon this: https://vitejs.dev/guide/migration.html#rework-define-and-import-meta-env-replacement-strategy
However, Vite's 5 behaviour it's still pure AST replacement (but consistent between dev and prod this time!)
In order to avoid having the same constant repeated multiple times and increasing our bundle size,
we are using the virtual modules to achieve the same behaviour. This way, we also have:
* Proper TypeScript support
* No need to configure the global in multiple places (like eslint config),
* No need for an environment.d.ts file anymore.
* The commit hash is a pure JavaScript const, we don't need to think about it differently
and workaround the mismatches from Vite that lead us to refactor the commit hash stamping
multiple times already.
Signed-off-by: Fernando Fernández <ferferga@hotmail.com>
