Update to LiveView 1.0 🎉

[solnic]

Closes #825

[solnic]

@whatyouhide what's the reasoning behind having mix.lock files in git?

[whatyouhide]

In general is so that you get reproducible mix deps.get every time instead of making it depend on what versions are up on Hex. For libraries like this one, dependants don't read mix.lock, it's only for local use when developing the library. Does it make sense?

[solnic]

In general is so that you get reproducible mix deps.get every time instead of making it depend on what versions are up on Hex. For libraries like this one, dependants don't read mix.lock, it's only for local use when developing the library. Does it make sense?

@whatyouhide yeah it does but the downside is that we're locking ourselves to specific versions, and then people release new versions of stuff we depend on and we're missing running our test suite against these updated versions. My approach for years was to always let the CI install whatever is the latest. This also helps catch installation issues early on. There are of course special cases like explicitly testing against a very specific set of versions for some crucial deps. In our case that would be of course Phoenix and LiveView.

I'm not saying we should remove the locks though, just raising this as a concern. We could solve this in various ways - like having dependabot configured for our needs, or a separate CI run that does mix deps.update --all.

[whatyouhide]

Yeah we shouldn't remove the locks. Dependabot is probably what we want here.

[marpo60]

👋 👋 👋

Not sure if it was on your radar but we built blend to solve this issue. You can test an hex package against different version of its dependencies.

This is an example of surface-ui testing against phoenix_live_view 0.20.x and 0.19.x

[phinnaeus]

@solnic it's best practice not just with elixir but in pretty much every language that supports it to commit your lockfiles. that's the whole point of the lockfile concept, for reproducibility. note this is not the same as vendoring your dependencies.

[whatyouhide]

Can you also rebase on master please? 🙃

[solnic]

@whatyouhide I'm not sure how to make this work with 1.13 and locks checked in. Any ideas? Do we need a separate lock for 1.13? When installing deps on CI we can't have locks that point to LV 1.0 because that will make 1.13 install it and crash. Having "~> 0.20 or ~> 1.0" doesn't make 1.13 install older LV (unsurprisingly).

...unless I'm missing something obvious?

[whatyouhide]

For now patch CI so that you run mix deps.unlock phoenix_live_view if the Elixir version is older. This is temporary anyway since it'll go away once we drop support for older Elixir versions.

[solnic]

@solnic it's best practice not just with elixir but in pretty much every language that supports it to commit your lockfiles. that's the whole point of the lockfile concept, for reproducibility. note this is not the same as vendoring your dependencies.

In my experience, it is FAR simpler to not have them checked in for OSS projects when you care about staying on top of the deps (as in, test against latest versions). Locks checked in make perfect sense for apps, but not for OSS libs. The whole point of running CI for OSS libs is to ensure that things don't break and your lib can be installed, it is so easy to get behind by an accident. I understand that you can have locks checked in and use other tools to inform you about outdated deps, but from a pragmatic/time-saver POV it is just extra work. I've found it to be just simpler and less time consuming to not have locks in OSS lib repos.

This is my personal opinion and experience - our situation here is different :)

[whatyouhide]

Peter, I have never experienced issues with checked-in lockfiles or had my time consumed 🙃 We have a path forward here, so let's just take that and merge this PR 💯

[phinnaeus]

@whatyouhide I'm not trying to argue or hold anything up, just for my own curiosity -- what's the problem with using >= 20.0? It seems like it would allow consumers to use either 1.0 or 0.20 unlike ~> 0.20 is equivalent to >= 0.20 and < 0.21.

[Munksgaard]

@phinnaeus: I'm pretty sure Mix supports or clauses in the version requirements. Perhaps "~> 0.20 or ~> 1.0" is more reasonable?

[solnic]

With "or" it still installs the latest version because that's what we have in the lock, unless I'm doing something wrong here :(

[solnic]

@whatyouhide I'm not trying to argue or hold anything up, just for my own curiosity -- what's the problem with using >= 20.0?

Open-ended dep requirements are problematic because 2.0.0 may no longer be compatible, we could have ">= 1.0 and < 2.0" though.

[phinnaeus]

Gotcha, yeah I understand now. To give context to my earlier replies, I wasn't considering the requirement to test against both 0.x and 1.x versions of Live View.

[solnic]

@whatyouhide @phinnaeus looks like I've made it 🙃 the trick was to skip doing deps.get in test/integrations since we don't even run these tests under 1.13, and also skip doing --check-locked under 1.13