Keeping Realm-JS up-to-date

realm / realm-studio

Realm Studio

https://realm.io/products/realm-studio/

Apache License 2.0

296 stars 38 forks source link

Keeping Realm-JS up-to-date #651

Open kraenhansen opened 6 years ago

kraenhansen commented 6 years ago

I noticed that Realm JS had fixes that didn't make it into a release of Studio. I suggest we setup some sort of CI that creates a PR upgrading Realm JS on this project whenever a new version of Realm JS becomes available:

[ ] Create a mechanism of getting notificed by new versions of Realm JS, as a downstream job on Jenkins or perhaps a daily polling of npm show realm versions.
[ ] Change the dependency on Realm JS to be anything with major version 2 (^2.0.0 or 2.x.x).
[ ] Automate pushing a branch to this repo with changes to the package-lock.json: Essentially running npm update realm and committing the changes.
[ ] Automate creating a PR from the branch.

For information about the NPM package lock and why this is needed - please read https://docs.npmjs.com/files/package-locks

bmunkholm commented 6 years ago

Isn't the loveliness of the JS ecosystem that you can just specify you want the latest? "realm: 2.x.x"

kraenhansen commented 6 years ago

That might be one of the lovelinesses - there are multiple ;)

But ... we still need a new build + release when a new version of Realm JS becomes available, for it to get to the users of Studio. I also would like to know which exact version of the dependencies that a particular commit uses, which is why we use a package-lock.json (or a yarn-lock.json) - otherwise two builds from the same commit sha might be behaving differently.

bmunkholm commented 6 years ago

You can see that with the lock file right? (all other dependencies are also automatically updated it seems). I'm not sure we need to make a new release of Studio, just because a new version of JS is released? This solution is cheap and works reasonably well now, the other requires more time.

kraenhansen commented 6 years ago

I think you're right that using a semantically compatible version instead of pinning might be better. We can update the lock by running npm update realm - but I would still want this to be explicit, so it's easier to checkout and test if anything breaks from having upgraded.