Removing `frontend-maven-plugin` and requiring installing Node.js manually

966 views
Skip to first unread message

Stian Thorgersen

unread,
Jan 24, 2024, 6:35:53 AM1/24/24
to
We've been using `frontend-maven-plugin` to install Node.js when building Keycloak. For those that don't know that's what builds the admin, account, and the JS adapter.

frontend-maven-plugin is not all that great, and has some downsides like it's regularly failing on GitHub Actions, and doesn't support parallel builds with Maven.

I've been thinking that we should stop using this plugin, require folks to install Node.js locally for a complete build, and then probably just use the exec plugin to run node directly.

In addition it would be good to have an option like `-DgetJsStuffFromSnapshot` that would disable building JS stuff, and instead just fetch the latest nightly build from snapshot repositories.

Thoughts?

Fesenmeyer Daniel (BD/SWD-BEB2)

unread,
Jan 24, 2024, 10:09:11 AM1/24/24
to stho...@redhat.com, Keycloak Dev
Thanks for the hint, now I've included the mailing list.
From: Stian Thorgersen <stho...@redhat.com>
Sent: Wednesday, January 24, 2024 3:11 PM
To: Fesenmeyer Daniel (BD/SWD-BEB2) <Daniel.F...@bosch.com>
Subject: Re: [keycloak-dev] Removing `frontend-maven-plugin` and requiring installing Node.js manually
 
Can you include the mailing list in the reply?

On Wed, 24 Jan 2024 at 14:57, Fesenmeyer Daniel (BD/SWD-BEB2) <Daniel.F...@bosch.com> wrote:
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.

Garth

unread,
Jan 24, 2024, 1:03:41 PM1/24/24
to Fesenmeyer Daniel (BD/SWD-BEB2), Stian Thorgersen, Till Markus (IOC/PAU1)
+1 for Daniel's perspective.

We use it in several applications, and have overcome the parallel builds problem the same way. We also found the developer to be helpful when we had issues, so maybe a route is to work together to debug and add features.

Also agree that it's core value proposition (handling the version that is necessary for the build) is great, as npm/nvm/pnpm can be a disaster to get consistent between developers' machines.

As an alternative, one idea we looked into to bring consistency to our own js builds was to use a docker container to do the building.

On Wed, Jan 24, 2024, at 4:09 PM, 'Fesenmeyer Daniel (BD/SWD-BEB2)' via Keycloak Dev wrote:
> Thanks for the hint, now I've included the mailing list.
> *From:* Stian Thorgersen <stho...@redhat.com>
> *Sent:* Wednesday, January 24, 2024 3:11 PM
> *To:* Fesenmeyer Daniel (BD/SWD-BEB2) <Daniel.F...@bosch.com>
> *Subject:* Re: [keycloak-dev] Removing `frontend-maven-plugin` and
> requiring installing Node.js manually
>
> Can you include the mailing list in the reply?
>
> On Wed, 24 Jan 2024 at 14:57, Fesenmeyer Daniel (BD/SWD-BEB2)
> <Daniel.F...@bosch.com> wrote:
>> 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
>>
>> We've been using `frontend-maven-plugin` to install Node.js when building Keycloak. For those that don't know that's what builds the admin, account, and the JS adapter.
>>
>> frontend-maven-plugin is not all that great, and has some downsides like it's regularly failing on GitHub Actions, and doesn't support parallel builds with Maven.
>>
>> I've been thinking that we should stop using this plugin, require folks to install Node.js locally for a complete build, and then probably just use the exec plugin to run node directly.
>>
>> In addition it would be good to have an option like `-DgetJsStuffFromSnapshot` that would disable building JS stuff, and instead just fetch the latest nightly build from snapshot repositories.
>>
>> Thoughts?
>>
>> --
>> 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 <https://groups.google.com/d/msgid/keycloak-dev/CAJgngAcWgCRd%2BSYETqf9JTQsOCUNor-UzbT8vRFwL5qHbQx3og%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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/AS1PR10MB5213F864105099E032C5A00BF87B2%40AS1PR10MB5213.EURPRD10.PROD.OUTLOOK.COM
> <https://groups.google.com/d/msgid/keycloak-dev/AS1PR10MB5213F864105099E032C5A00BF87B2%40AS1PR10MB5213.EURPRD10.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

Jon Koops

unread,
Jan 25, 2024, 11:21:34 AM1/25/24
to Keycloak Dev
Forwarding this to Keycloak dev, let's continue the conversation here.

---------- Forwarded message ---------
From: Jon Koops <jko...@redhat.com>
Date: Thu, Jan 25, 2024 at 5:18 PM
Subject: Re: Removing `frontend-maven-plugin` and requiring installing Node.js manually
To: <keyclo...@redhat.com>


Ok so from what I am seeing there are two options:

1. Keep the front-end plugin and:
  - Move the Node.js setup to the project root and only run it once (see #24537)
  - Download and cache the Node.js binary between CI runs (see #25387)

2. Remove the front-end plugin and:
  - Run Node.js and PNPM directly from system binaries (see #26461)
  - Enforce the correct Node.js and PNPM versions with engines and engine-strict.

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 file 


This 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

Garth

unread,
Jan 25, 2024, 11:57:01 AM1/25/24
to keyclo...@googlegroups.com
#1!

On Thu, Jan 25, 2024, at 5:21 PM, Jon Koops wrote:
> Forwarding this to Keycloak dev, let's continue the conversation here.
>
> ---------- Forwarded message ---------
> From: *Jon Koops* <jko...@redhat.com>
> Date: Thu, Jan 25, 2024 at 5:18 PM
> Subject: Re: Removing `frontend-maven-plugin` and requiring installing
> Node.js manually
> To: <keyclo...@redhat.com>
>
>
> Ok so from what I am seeing there are two options:
>
> 1. Keep the front-end plugin and:
> - Move the Node.js setup to the project root and only run it once
> (see #24537 <https://github.com/keycloak/keycloak/pull/24537>)
> - Download and cache the Node.js binary between CI runs (see #25387
> <https://github.com/keycloak/keycloak/pull/25387>)
>
> 2. Remove the front-end plugin and:
> - Run Node.js and PNPM directly from system binaries (see #26461
> <https://github.com/keycloak/keycloak/pull/26461>)
> - Enforce the correct Node.js and PNPM versions with engines
> <https://pnpm.io/package_json#engines> and engine-strict.
>
> 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 <https://vitejs.dev/guide/features.html#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 file
>>>
>>>
>>> This 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
>>>
>
> --
> 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/CAEdmLYE%3DPo%3DeNa%3DhOeEEVt6kUbT2miW1DyoxTzn3S006Qo15iw%40mail.gmail.com
> <https://groups.google.com/d/msgid/keycloak-dev/CAEdmLYE%3DPo%3DeNa%3DhOeEEVt6kUbT2miW1DyoxTzn3S006Qo15iw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Fesenmeyer Daniel (BD/SWD-BEB2)

unread,
Jan 25, 2024, 12:16:44 PM1/25/24
to Garth, keyclo...@googlegroups.com
#1 +1 🙂
From: keyclo...@googlegroups.com <keyclo...@googlegroups.com> on behalf of Garth <ga...@tunnel19.com>
Sent: Thursday, January 25, 2024 5:56 PM
To: keyclo...@googlegroups.com <keyclo...@googlegroups.com>
Subject: Re: [keycloak-dev] Fwd: Removing `frontend-maven-plugin` and requiring installing Node.js manually
 
#1!

On Thu, Jan 25, 2024, at 5:21 PM, Jon Koops wrote:
> Forwarding this to Keycloak dev, let's continue the conversation here.
>
> ---------- Forwarded message ---------
> From: *Jon Koops* <jko...@redhat.com>
> Date: Thu, Jan 25, 2024 at 5:18 PM
> Subject: Re: Removing `frontend-maven-plugin` and requiring installing
> Node.js manually
> To: <keyclo...@redhat.com>
>
>
> Ok so from what I am seeing there are two options:
>
> 1. Keep the front-end plugin and:
>   - Move the Node.js setup to the project root and only run it once

>   - Download and cache the Node.js binary between CI runs (see #25387

>
> 2. Remove the front-end plugin and:
>   - Run Node.js and PNPM directly from system binaries (see #26461

>   - Enforce the correct Node.js and PNPM versions with engines

>
> 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
>>
>>
>> > 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
>>>

>>>
>>>> - 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 file
>>>
>>>
>>> This 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
>>>
>
> --
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkeycloak-dev%2FCAEdmLYE%253DPo%253DeNa%253DhOeEEVt6kUbT2miW1DyoxTzn3S006Qo15iw%2540mail.gmail.com&data=05%7C02%7Cdaniel.fesenmeyer%40bosch.com%7Cd98758a86cab48d6fc7508dc1dc6a72a%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638417988104037342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C41000%7C%7C%7C&sdata=ensf8NvPvk4paI7qoWLctGUCpVFjozuW2mJa%2BOtILDs%3D&reserved=0
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fkeycloak-dev%2FCAEdmLYE%253DPo%253DeNa%253DhOeEEVt6kUbT2miW1DyoxTzn3S006Qo15iw%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cdaniel.fesenmeyer%40bosch.com%7Cd98758a86cab48d6fc7508dc1dc6a72a%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638417988104041666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C41000%7C%7C%7C&sdata=JF8tKHcwwrKa1Uvhv5GdTH4uu2JjubD8xUt0TD4u9lE%3D&reserved=0>.


--
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.

Marek Posolda

unread,
Jan 25, 2024, 12:39:07 PM1/25/24
to Fesenmeyer Daniel (BD/SWD-BEB2), Garth, keyclo...@googlegroups.com
+1 to #1 if possible and continue with maven frontend plugin. I afraid of worse developer experience if we require people to deal with node/pnpm stuff on their laptops when they want to contribute something to Keycloak.

Marek

Schuster Sebastian (BD/CTA-SAR)

unread,
Jan 25, 2024, 1:42:03 PM1/25/24
to keyclo...@googlegroups.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 


Date: Thursday, 25. January 2024 at 18:39
To: Fesenmeyer Daniel (BD/SWD-BEB2) <Daniel.F...@bosch.com>

Jon Koops

unread,
Mar 28, 2024, 8:09:00 AM3/28/24
to keyclo...@redhat.com, Keycloak Dev
Re-adding the dev mailing list for good measure, it got lost along the way.

On Thu, Mar 28, 2024 at 1:06 PM Jon Koops <jko...@redhat.com> wrote:
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:
  - Move the Node.js setup to the project root and only run it once (see #24537)
  - Download and cache the Node.js binary between CI runs (see #25387)

2. Remove the front-end plugin and:
  - Run Node.js and PNPM directly from system binaries (see #26461)
  - Enforce the correct Node.js and PNPM versions with engines and engine-strict.

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 file 


This 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

Jon Koops

unread,
Apr 2, 2024, 5:03:50 AM4/2/24
to keyclo...@redhat.com, Keycloak Dev
I'll be merging the PR by end-of-day CET, please get your reviews in by then, thanks!
Reply all
Reply to author
Forward
0 new messages