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

Wed Nov 27 01:46:03 EST 2019

You could also start with something simple, just move the package.json,
tooling (bundling, unit testing) in the same folder with an index.js.

I am working on my side to create a version in Typescript for modern
browsers without cookie or iframe.
It would be more interesting to converge efforts in the same direction.
But it's up to the Keycloak team to initiate the movement.

I have also some time for this effort.

On Tue, Nov 26, 2019 at 4:53 PM Jon Koops <jonkoops at gmail.com> wrote:

> This is a great idea, splitting this client out into a separate repository
> will allow us to be more flexible and efficient in developing out the
> JavaScript adapter. Also being able to use tooling that is common in the
> community such as using a proper bundler for dependencies, writing modern
> ES2015 code, shipping compatible ES5 code to those who need it and writing
> type safe code using TypeScript could be a huge boon to the project and
> development speed. Moving everything to NPM should also give us proper
> control over deprecations, where now we cannot easily deprecate and remove
> functionality since there is no version control when loading the static
> assets. It also allows us to improve the testing situation by moving away
> from the current and outdated testing methods.
>
> I would be very interested in helping out with the development of this
> library so let me know if I can be of any help. If we're going with a new
> library I would also propose that we rename the library to
> 'keycloak-client' on NPM since the fact that it is hosted there should
> already indicate that we're talking about JavaScript and perhaps publish it
> to `@keycloak` organisation on NPM. I'd also like to propose to move issue
> management of this project to Github, as it decreases the effort to
> contribute to the project.
>
>
>
> On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > 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
> > >
> > >
> > _______________________________________________
> > 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

-- 

Guillaume Vincent

Senior Software Engineer

Red Hat <https://www.redhat.com>
<https://www.redhat.com>