fix: image build

[pat-s]

These patches are required to get the Dockerfile built (with node:lts-alpine).

See also:

• https://codefloe.com/devxy/container-images-misc/src/branch/main/images/rdepot-frontend/Containerfile
• https://hub.docker.com/repository/docker/devxygmbh/rdepot-frontend/general

Would like to switch back to the upstream source again, once fixed.

[jvanmalder]

Hi @pat-s
Thank you for your PR.
I was wondering which issue(s) you had while building the Docker image?
I just tried building it with both the latest node:lts-alpine and node:lts-alpine3.20 images and have had no issues doing so.

[pat-s]

I did a standard docker buildx build on the given repo state and encountered many issues related to the underlying npm packages and their interconnected use.

The fixes above were needed to get a build going in the first place (for the build stage).

It would be easier to spot/reference if there would be an open build process for all the images, regardless of whether they are being stored in your own registry or on dockerhub and friends 🙂️

(PS: just as a side-note to all the image building approaches: most openanalytic images are quite out-of-date WRT to the base images and other deps. And include a lot of things which are not needed to get the app running. Example: in the repo I linked, I built rdepot-backend with an up-to-date base image stack (alpine 3.21, Java 24) and stripped all unnecessary deps. The image is 6.6x times smaller than the default one currently referenced in the examples (471MB vs 3.19GB)).

[jvanmalder]

Since we are using Vue 3 (and vue3-apexcharts), the recommended way to register is app.use(VueApexCharts) (see https://apexcharts.com/docs/vue-charts/)

[jvanmalder]

Ideally, in this case also "allowImportingTsExtensions": true should be used. See https://vite.dev/guide/performance.html#reduce-resolve-operations.

[jvanmalder]

I did a standard docker buildx build on the given repo state and encountered many issues related to the underlying npm packages and their interconnected use.

The fixes above were needed to get a build going in the first place (for the build stage).

It would be easier to spot/reference if there would be an open build process for all the images, regardless of whether they are being stored in your own registry or on dockerhub and friends 🙂️

(PS: just as a side-note to all the image building approaches: most openanalytic images are quite out-of-date WRT to the base images and other deps. And include a lot of things which are not needed to get the app running. Example: in the repo I linked, I built rdepot-backend with an up-to-date base image stack (alpine 3.21, Java 24) and stripped all unnecessary deps. The image is 6.6x times smaller than the default one currently referenced in the examples (471MB vs 3.19GB)).

Ok, thanks for the quick reply.
I'll discuss adding these suggestions to the roadmap in the short term with the rest of the team.