9:09 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev