Deprecate SolidusFrontend

[gsmendoza]

Goal

We want to deprecate SolidusFrontend so that developers, especially those
building fresh Solidus apps, will choose to SolidusStarterFrontend instead.

Background

This is part of an epic to replace the SolidusFrontend gem with SolidusStarterFrontend.

Screenshots

frontend 14:51:29 $ gem install solidus_frontend-3.2.0.alpha.gem
----------------------------------------------------------------------------
DEPRECATION WARNING: SolidusFrontend is deprecated. It will be removed from
the solidus meta-package gem in a Solidus v4. Furthermore, its code will be
extracted from https://github.com/solidusio/solidus to a new repo. Once
extracted, you'll need to explicitly add `solidus_frontend` to your Gemfile
in order to continue using it.

For fresh Solidus applications, we recommend you use SolidusStarterFrontend
instead.
----------------------------------------------------------------------------
Successfully installed solidus_frontend-3.2.0.alpha
Parsing documentation for solidus_frontend-3.2.0.alpha
Done installing documentation for solidus_frontend after 0 seconds
1 gem installed

Checklist:

• I have followed Pull Request guidelines
• I have added a detailed description into each commit message
• N/A: I have updated Guides and README accordingly to this change (if needed)
• N/A: I have added tests to cover this change (if needed)
• N/A: I have attached screenshots to this PR for visual changes (if needed)

[waiting-for-dev]

Thanks, @gsmendoza!

Any chance we could reuse Spree::Deprecation module for that? Example: https://github.com/peterberkenbosch/solidus/blob/d2035bfb6644d913e4b76ddae7d72799ef27e936/core/app/models/spree/order.rb#L385

Also, if you like, we could talk about this change and its motivation in the Other important changes in the Changelog. If we add it now, we won't have to remember later 🙂

[gsmendoza]

Thanks @waiting-for-dev ! I'll make the following updates:

• Use Spree::Deprecation.
• Update Changelog.

[kennyadsl]

I think this message is not clear. We don't want people currently using solidus_frontend to start using the new frontend because they would have to rebuild their frontend entirely. I think what we want to say to people is that, this gem will be removed from the meta-package solidus and if they still want to use it, they need to add it manually to the Gemfile, isn't it?

[gsmendoza]

@kennyadsl How about this:

NOTE: SolidusFrontend is deprecated. It will be moved out of the solidus meta-package gem in a future version of Solidus. Once moved out, you'll need to manually add solidus_frontend to your Gemfile in order to continue using it.

For fresh Solidus applications, we recommend you use SolidusStarterFrontend instead.

[kennyadsl]

I think the text of the message may work. I'm only a bit concerned that, with this approach, there's no way to remove the deprecation message until we actually remove solidus_frontend from solidus. Is there a way to check that solidus_frontend is present in the Gemfile and print the message only otherwise? Or do you have any other idea about how to fix this?

[waiting-for-dev]

Is there a way to check that solidus_frontend is present in the Gemfile and print the message only otherwise?

That question intrigued me 🙂 It seems we can get the information through:

Bundler.locked_gems.dependencies

However, it seems to be very slow. I don't know if there's a way to cache it thanks to the bundler/setup Rails apps do in config/boot.rb

[kennyadsl]

and probably move the message at the boot phase so that, even if it's slow it only happens once when the application boots (but maybe it's the same in this file?).

[waiting-for-dev]

@gsmendoza, I'm not sure I follow. solidus_frontend is already a standalone gem. Then, it's a dependency on solidus meta-gem.

[kennyadsl]

Yes, this does solve! 🙂

You are right, if people switch to the gem in the Gemfile they will be able to get the version without the deprecation notice. There's just one thing to address: we need to understand how the versioning of those two gems will work, because both need to be on RubyGems, and they can't have the same version.

[kennyadsl]

@waiting-for-dev we can move solidus_frontend to another GitHub repository, remove it as a dependency of solidus, and start publishing new versions on RubyGems of it from its own new repository only. Do you see any issue with this approach?

[waiting-for-dev]

Oh, I get it. Yeah, makes sense 🙂

[gsmendoza]

we need to understand how the versioning of those two gems will work, because both need to be on RubyGems, and they can't have the same version.

@kennyadsl I remember your idea before is to give the external gem a different name e.g. solidus_deprecated_frontend. If we do that, we can maintain both solidus_frontend and solidus_deprecated_frontend in RubyGems :)

[gsmendoza]

@kennyadsl @waiting-for-dev I updated the deprecation message based on our offline discussion. Appreciate if you can take a look. Thanks!

[waiting-for-dev]

Again, maybe we can be cautious here and make it clearer that we're not recommending old storefronts built on top of solidus_frontend to replace it.

[waiting-for-dev]

I'd say "solidus meta-package" (with initial "s" in lower case), as that's the name of the gem, and people will be less confused.

Maybe we can specify that the Solidus version where it'll be removed will be 4.0.

Other than that, it's very clear 👍

[gsmendoza]

I'd say "solidus meta-package" (with initial "s" in lower case), as that's the name of the gem, and people will be less confused.

I'm okay with that, since "solidus" specifically refers to the gem. But how about SolidusFrontend and Solidus in "in a future version of Solidus"? For those, let's keep the camel case?

[waiting-for-dev]

Thanks, @gsmendoza!!

[kennyadsl]

This repository is a demonstration that the solidus_frontend "as-an-extension" works by just unpacking the full solidus gem and adding it as a standalone dependency.

We can go ahead!