Open kraenhansen opened 6 years ago
Isn't the loveliness of the JS ecosystem that you can just specify you want the latest? "realm: 2.x.x"
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.
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.
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.
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:
npm show realm versions
.^2.0.0
or2.x.x
).npm update realm
and committing the changes.For information about the NPM package lock and why this is needed - please read https://docs.npmjs.com/files/package-locks