docs: get started docs r-r version

[adnjoo]

Summary

edit get-started.md to include latest version of react-rails #1324

Other Information

Pull Request checklist

Remove this line after checking all the items here. If the item is not applicable to the PR, both check it out and wrap it by ~.

- [] Add/update test to cover these changes

• Update documentation
  - [ ] Update CHANGELOG file

[ahangarha]

This way, we should update the docs for every single release. Isn't it?

[adnjoo]

hmm how about like bundle add 'react-rails' --strict --version '>=3.1.1'

[ahangarha]

It is important to install "exact" version for both the Ruby gem and node package. This is emphasized in the documentation as well.

[ahangarha]

We should use "exact" version.

[ahangarha]

But I see one point. --strict doesn't count the patch version and when we have fixes and bump the patch value in the version, --strict doesn't help.

If there is any better proposal (than manually fix the version) please share.

CC: @Judahmeek @justin808

[justin808]

I'm not seeing the value of any changes. What am I missing?

[G-Rath]

Is there a reason why we're suggesting using --strict in the first place?

[ahangarha]

Is there a reason why we're suggesting using --strict in the first place?

Because bundle add react-rails adds gem "react-rails", "~> 3.1" which means any 3.x version of react-rails. Since react-rails have both Ruby and Node sides, we need to ensure we use "exact" and the same versions for both.

Any suggestion?

I can think of making some hooks in our release script to bump the version in the documentation as well. Not ideal.

[G-Rath]

ah right it's react_ujs and it's installed by rails generate react:install which is why it's not listed in the getting started docs.

As I've pushed for over in Shakapacker, I don't think we should be encouraging people to pin to exact versions since it tends to make things more brittle in managing updates (especially for security fixes), and the whole ideal of patch versions is they should not be breaking - I know it's not impossible for there to be a dependency between the Ruby and JS versions of the package for a particular bug fix, but in reality how often has that actually happened?

I think the better long-term path is to help the user ensure the versions are in sync like what's being done in Shakapacker - effectively shakacode/shakapacker#156, which probably could be done by just copying over the version detection logic stuff? Noting though I have actually somewhat deliberately ignored this part of react-rails for the time being to focus on the package_json work because unlike with Shakapacker I have not run into any version mismatch issues and I think it might make sense for some of the JS version stuff to actually live in package_json, but don't want to rush into it and end up with a poor design.

tbh it feels like a bug in Bundler that --strict does not give you the latest patch version, given there's no other way to dynamically resolve the latest version with --strict...

[ahangarha]

tbh it feels like a bug in Bundler that --strict does not give you the latest patch version, given there's no other way to dynamically resolve the latest version with --strict...

I agree. Twice, I thought about it but then left the issue. Perhaps they cannot change the behavior of the strict option but maybe can add --strict-patch option. Strict should mean STRICT!!! But... 😄

[justin808]

@ahangarha @G-Rath ready to merge?

[justin808]

If this changes, then we should also change react_on_rails for the same issue.

We have this documentation: https://www.shakacode.com/react-on-rails/docs/getting-started/

[ahangarha]

@justin808
I am not in favor of this change.

The only solution I can think of is to update the docs in our release script.
Otherwise, I think we should keep the docs the way it is.

[ahangarha]

By the way, thanks for the initiative.
@adnjoo

[adnjoo]

@ahangarha np, thanks for reviewing :)