[keycloak-dev] Extract Javascript Adapter into separate keycloak-js repository

[Stian Thorgersen]

With regards to a new version of keycloak.js the question comes up if
AppAuth-JS [1] can be used instead.

[1] https://github.com/openid/AppAuth-JS

On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger at redhat.com> wrote:

> keycloak.js doesn't have to be in the same repository to make sure it is
> compatible or release at the same time. Just look at the Node.js adapter
> for example.
>
> If we want to rewrite keycloak.js using modern approaches and clean it up.
> I would introduce a new repository with a new version of keycloak.js that
> doesn't have to worry about backwards compatibility. That can also be
> tested using modern JS test tools.
>
> That way we can maintain/deprecate the old keycloak.js and eventually
> replace it with the new modern version.
>
> In the future we should also not have a dependency on keycloak.js in our
> admin console and new account console. Basically best practices state that
> if you have both SPA and REST APIs on the same domain use cookies and
> confidential clients, not tokens in the browser and public clients.
>
> On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 11/26/2019 5:03 AM, Armin Roșu wrote:
>> > Hello,
>> >
>> > We were having a discussion about unit testing keycloak-js in this PR:
>> > https://github.com/keycloak/keycloak/pull/5946 (closed).
>> >
>> > An easy way would be to extract it into a separate repository and write
>> > unit tests there.This would bring further benefits:
>> There are advantages and disadvantages to putting keycloak-js in a
>> separate repo.
>>
>> The main advantage I see for having it in the same repo with Keycloak
>> server is that keycloak.js version is always synced with the Keycloak
>> server version.  For any client/server system there are always nasty
>> issues that crop up when client and server versions diverge.
>> >
>> > - keycloak.js can be refactored to Typescript
>> There are definite advantages in code quality when you use TypeScript.
>> This is both in the maintainability of the source code and the quality
>> of the generated keycloak.js file.  If we know there are dedicated
>> resources to develop the Typescript version and the associated test
>> suite then I'm all for it.  But that might be a big "if".
>> > - file can be split in multiple modules
>> > - independent versioning from keycloak/keycloak would enable deprecating
>> > legacy Promises by enabling developers to use the keycloak-js version
>> that
>> > works for them
>> > - keycloak-js-bower could also be deprecated.
>> >
>> > Guillaume Vincent previously proposed rewriting the Javascript Adapter (
>> >
>> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
>> ).
>> > Extracting it, writing tests for it and rewriting it afterwords is an
>> > option less prone to breaking changes.
>> >
>> >
>> > I have some free time and could start work on this.
>> >
>> > What do you think? Should I set up a repo so we can talk over code?
>> >
>> > Cheers,
>> > Armin
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>