Updating Svelte to v4 (and other frontend dependencies)

scylladb / argus

Apache License 2.0

4 stars 11 forks source link

Updating Svelte to v4 (and other frontend dependencies) #458

Open k0machi opened 2 months ago

k0machi commented 2 months ago

We haven't updated our frontend dependencies in a while and the v3 branch of Svelte is getting less and less support as it's a very bleeding edge library that gets constant improvements. We should update and migrate our code to v4. Looking at the doc there, there aren't a lot of changes needed (if any), so it should be a relatively smooth procedure. However:

Svelte-select has breaking api changes going from our current version to latest, which would necessitate updating our usage of Select component.
We should update svelte-loader and webpack (or, potentially, switch to rollup for bundling, as that's the official recommendation)
Bootstrap could be updated as well during this.

fruch commented 1 week ago

@k0machi

what is the added value of such update ? is that blocking anything ?

is there any bug fixes we need from the new version ?

i.e. we need a good reason to start this thing.

k0machi commented 1 day ago

@k0machi

what is the added value of such update ? is that blocking anything ?

is there any bug fixes we need from the new version ?

i.e. we need a good reason to start this thing.

Libraries that we use have started requiring v4, so to update them (particularly the select component) we would need to update svelte as well. v4 migration is easy, there's just one minor change that needs to be accounted for, v5 on the other hand will require a small refactor and can be postponed.

fruch commented 1 day ago

@k0machi what is the added value of such update ? is that blocking anything ? is there any bug fixes we need from the new version ? i.e. we need a good reason to start this thing.

Libraries that we use have started requiring v4, so to update them (particularly the select component) we would need to update svelte as well. v4 migration is easy, there's just one minor change that needs to be accounted for, v5 on the other hand will require a small refactor and can be postponed.

if we have specific library that we need to update and mante this change, let's do that in the context of that needed change.

i.e. no change for the sake of updates only, and not update too many thing at the same time, just for the sake of it. it should be small incremental changes as much as possible, not one big PR turning everything upside down