Hi Stian,
we are using "frontend-maven-plugin" for a few weeks now.
We also faced some issues, but found workarounds which seem to work fine till now:
We also had issues with parallel builds, because the download of node/npm/pnpm fails when the corresponding goal is run for multiple modules in parallel. We could workaround that by executing that goal (install-node-and-pnpm) just once in a common parent/aggregator module.
In Azure Devops, we got download errors in our matrix jobs (about 20 jobs in parallel). It seems like npm blocked our downloads because of too much traffic. To avoid this, we now cache the downloaded node/pnpm artifacts and configure frontend-maven-plugin to use this cache.
I think one of the biggest advantages of "frontend-maven-plugin" is that it simplifies development for backend developers. And that it makes it obvious which version of pnpm and node is necessary for the build.
Mit freundlichen Grüßen / Best regards
Daniel Fesenmeyer
Product Area User Management 2 (BD/PAU2)
Robert Bosch GmbH | Postfach 10 60 50 | 70049 Stuttgart | GERMANY | www.bosch.com
Tel. +49 30 403659-478 | Telefax +49 7545 202-301 | Daniel.F...@bosch.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer;
Geschäftsführung: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner,
Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert
From: keyclo...@googlegroups.com <keyclo...@googlegroups.com> on behalf of Stian Thorgersen <stho...@redhat.com>
Sent: Wednesday, January 24, 2024 12:35 PM
Subject: [keycloak-dev] Removing `frontend-maven-plugin` and requiring installing Node.js manually
--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAcWgCRd%2BSYETqf9JTQsOCUNor-UzbT8vRFwL5qHbQx3og%40mail.gmail.com.
Yeah, IMHO we should just make a PoC and see how feasible it is. But I think it's out of scope for resolving this immediate issue.> This is not true, the reason vite uses rollup is because they want more flexibility seeAh, then this has changed. It used to come with a big fat disclaimer that esbuild was not production ready. I think it still applies for the Build Optimizations section, but good to see it advancing.
> but there are challenges to overcome with this approach for sure, and I don't have the answers to all of them, just wanted to point this out as a possibilityOn Thu, Jan 25, 2024 at 3:39 PM Erik Jan de Wit <ede...@redhat.com> wrote:- Production builds with esbuild are still not recommended, hence Vite uses Rollup for productionThis is not true, the reason vite uses rollup is because they want more flexibility see https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild- How do handle workspace dependencies, e.g. Admin Client library, which is a dependency of the Account Console through the workspace.Right, we will no longer be able to use workspaces that's definitely something that will be missed and that we need to figure out- It seems to be optimized for bundling, but for libraries we don't want to bundle everything in a single file.Also there are options to configure this, you don't have to have everything in a single fileThis is also not an issue esbuild can do- How do we handle type-checking during development- How do we handle Hot Module Replacement during development (e.g React Fast Refresh).
The list goes on. Not saying this isn't possible, but it would be a significant effort that would likely result in us having to contribute upstream to Quarkus Web Bundler to add some missing features.So the list with the things that can't be done isn't that long, but there are challenges to overcome with this approach for sure, and I don't have the answers to all of them, just wanted to point this out as a possibility
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/AS1PR10MB52130BBAD4CABE3D4306B4C6F87A2%40AS1PR10MB5213.EURPRD10.PROD.OUTLOOK.COM.
Also +1 for #1.
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Chapter - Customer Touchpoints-Digital Sales-Customer Touchpoints Solution Architects
(BD/CTA-SAR)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY | www.bosch.com
Besucheradresse: Borsigstraße 4 | 70469 Stuttgart
Mobil +49 152 02177668 |
Telefax +49 30 726112-100 | sebastian...@bosch.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer;
Geschäftsführung: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner,
Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert
From: keyclo...@googlegroups.com <keyclo...@googlegroups.com> on behalf of Marek Posolda <mpos...@redhat.com>
Date: Thursday, 25. January 2024 at 18:39
To: Fesenmeyer Daniel (BD/SWD-BEB2) <Daniel.F...@bosch.com>
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAE8YqZ--RfVU2DRywwcR4rg%3D3%3DogngyhY4NkQ1xAz5fWz%3D79sA%40mail.gmail.com.
Hi all, it's been a while since we last spoke, but after removing version 2 of the Account Console we're finally in a place where we can start consolidating our JavaScript projects into the same workspace. I've got a PR up that I intend to get merged early next week, so if you are interested please put in your review.On Wed, Feb 7, 2024 at 3:03 PM Stian Thorgersen <stho...@redhat.com> wrote:😐On Wed, 7 Feb 2024, 12:33 Jon Koops, <jko...@redhat.com> wrote:Sounds like the consensus here is to keep the front-end-plugin around and cache the setup work, plus further consolidating the front-end related setup work. I am waiting until after the release of 24 to do so, as we will be removing Account Console v2, which is currently blocking the consolidation efforts due to it deviating from the rest of the project significantly in regards to dependencies and tooling.On Fri, Jan 26, 2024 at 7:21 AM Erik Jan de Wit <ede...@redhat.com> wrote:I'm for 2
On Thu, Jan 25, 2024 at 5:18 PM Jon Koops <jko...@redhat.com> wrote:
Ok so from what I am seeing there are two options:1. Keep the front-end plugin and:
2. Remove the front-end plugin and:
- Run Node.js and PNPM directly from system binaries (see #26461)
Please cast your votes now 🗳️
On Thu, Jan 25, 2024 at 5:11 PM Jon Koops <jko...@redhat.com> wrote:
> This is not true, the reason vite uses rollup is because they want more flexibility see
Ah, then this has changed. It used to come with a big fat disclaimer that esbuild was not production ready. I think it still applies for the Build Optimizations section, but good to see it advancing.
> but there are challenges to overcome with this approach for sure, and I don't have the answers to all of them, just wanted to point this out as a possibility
Yeah, IMHO we should just make a PoC and see how feasible it is. But I think it's out of scope for resolving this immediate issue.
On Thu, Jan 25, 2024 at 3:39 PM Erik Jan de Wit <ede...@redhat.com> wrote:
- Production builds with esbuild are still not recommended, hence Vite uses Rollup for production
This is not true, the reason vite uses rollup is because they want more flexibility see https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild
- How do handle workspace dependencies, e.g. Admin Client library, which is a dependency of the Account Console through the workspace.Right, we will no longer be able to use workspaces that's definitely something that will be missed and that we need to figure out- It seems to be optimized for bundling, but for libraries we don't want to bundle everything in a single file.Also there are options to configure this, you don't have to have everything in a single fileThis is also not an issue esbuild can do- How do we handle type-checking during development- How do we handle Hot Module Replacement during development (e.g React Fast Refresh).
The list goes on. Not saying this isn't possible, but it would be a significant effort that would likely result in us having to contribute upstream to Quarkus Web Bundler to add some missing features.So the list with the things that can't be done isn't that long, but there are challenges to overcome with this approach for sure, and I don't have the answers to all of them, just wanted to point this out as a possibility
--Cheers,Erik Jan