-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider relaxing the version check and making it more consistent #156
Comments
Thanks @G-Rath Good thoughts! We don't look in the Gemfile as we're getting current version from gem itself. Agree that this makes messaging bit confusing. We do try and guide people to exact version in the installation instructions and template scripts ( Digesting what you're asking for/suggesting - am I right thinking that ideal setup gets rid of the exact/non-exact versions checks and just shouts at you if the installed combination ends up with two different versions? This would be pretty neat but it does create some issues. We can be pretty certain about gem version - we're doing check in the gem itself, it knows what it is! npm package however - that's bit more tricky. The more elegant version needs more information. Either some parsing of Don't have a solution on hand but will ponder this, suggestions and PRs also welcome! |
Parsing the Gemfile.lock and yarn.lock could be better. PRs welcome! |
Yes that is what I think would be the ideal.
🤦 yeah for some reason I thought you had the exact version of the npm package already and that was just silly.
Luckily I've actually created stable lockfile parsers for *: I'd like to include support for |
here you go
output
|
@G-Rath Please submit a PR. |
@justin808 yup will do when I've got the time - just wanted to put that here in the meantime incase anyone else had comments or time to take it further :) Hopefully I'll have some time for a PR on Friday. |
Nice one @G-Rath ! Looking good on the first glance, will just need to make sure we can support both yarn v1 and berry lockfiles. And yeah, getting support for non-yarn package managers (or well, at least npm), could be useful. Apart from installation and hardcoded usage, there should be no reason (famous last words), why NPM wouldn't work |
@tomdracz yeah that parser is a direct reimplementation of |
It's great to see that we've got
ensure_consistent_versioning
but I feel like it's missing the mark a bit and has inconsistent behaviour.Sample of current output for reference:
package.json
~> 6.0
)ensure_consistent_versioning
should mean we can use non-exact versions since we'll be told if the gem and npm package do not matchIt's really that last point that I want to talk about: generally it's considered bad practice to depend on an exact version as it makes it harder to do upgrades (especially for security patches) and it's generally a smell of a brittle setup if patch versions (which are meant to be the most non-breaking of changes) matter.
I totally get why it's important to ensure the gem and package are on the same version for this library and that's why I think having
ensure_consistent_versioning
is the way to go because it should actually allow us to avoid needing to use exact constraints as if something results in the gem being updated, we'll get told we have to update the package, and vice versa.The text was updated successfully, but these errors were encountered: