Investigate Dependency on Activesupport

[chawes13]

Having activesupport as a pinned dependency (currently at ~>5.2.0) can make it difficult for existing Rails projects to stay up-to-date with new Decanter features since upgrading activesupport virtually always will also require a rails update. While in theory these applications should be applying rails updates regularly, that's not necessarily something that our teams currently have the bandwidth for.

The premise of this ticket is to research the benefits that activesupport is currently providing (e.g., HashWithIndifferentAccess) and determine if there is a feasible migration path.

cc: @dianacamacho

[dianacamacho]

@chawes13 just ran into a related issue on a rails 6 project: having issues with newer decanter version because now active support for Rails 6.0.3.2 is at 6.0.3.2 (therefore not within the allowed versions for ~>5.2.0), so the dependency update seems to affect both older AND newer apps.

thoughts on at least starting with an update to >= 5.2.0 rather than pinning it to 5.2.x ?

Bundler could not find compatible versions for gem "activesupport":
  In Gemfile:
    decanter was resolved to 3.4.0, which depends on
      activesupport (~> 5.2)

    rails (~> 6.0.3, >= 6.0.3.2) was resolved to 6.0.3.2, which depends on
      activesupport (= 6.0.3.2)

[chawes13]

🤦 oof, I was worried about this. I'm having a hard time finding documentation or conversations about the dilemma that using activesupport introduces. Have you seen anything?

After doing a bit of research, it seems like one potential solution would be to limit the packages that we're using (instead of require/activesupport/all and tracking security vulnerabilities specific to those particular features. It seems like this would require investigation into a lot of activesupport's dependencies and likely a significant amount of overhead.

In terms of my investigation into what it would look like to remove the dependency, here's a list of everything that I think we're getting from activesupport. There's a good chance this list is not exhaustive. It looks like singularize (using ActiveSupport::Inflector) may be the biggest benefit / rationale for keeping the dependency.

• blank?
  • Fairly simple to rewrite (or replace usage)
• camelize
  • Could be rewritten / copied over
• constantize
  • Could be copied over but pretty intense; standalone gem?
• singularize
  • Don't want to even try. Unfortunately I couldn't find any obvious standalone gems
• wrap
  • Fairly simple to rewrite
• try
  • Fairly simple to rewrite (or replace usage)
• HashWithIndifferentAccess
  • Could use OpenStruct
• run_load_hooks
  • TBD

Or is the best solution to not pin a version at all and pass the responsibility of keeping the package up to date to each repo via bundle updates?

cc: @inveterateliterate, @dpikt

[chawes13]

@inveterateliterate It looks like you may have run into this a few months ago with rails_util, eh? Any advice here?

[inveterateliterate]

I think @dianacamacho's suggestion makes sense. Unless the objective is to make decanter usable for non-Rails apps I think just easing up on the pinning approach would be the way to go. Looks like in rails_util I didn't quite do Diana's suggestion but yeah we could do something like >= 5? (or start at 5.2.0 if we have concerns about anything before that)

To your investigation, those seem to me like core methods that aren't likely to change with upgrades to activesupport so I wouldn't anticipate that migrating rails / activesupport over the course of a project would break decanter?

[chawes13]

I guess I've always thought of this as a hash parser that could theoretically be used with any framework, but if we're explicitly considering it to the part of the rails ecosystem than that would make the unpinned activesupport approach make the most sense to me (a la rails_util)

[inveterateliterate]

I agree with that I guess I was maybe more specifically addressing Diana / our teams' more immediate concerns of being able to upgrade Decanter on our active Rails projects.

However, the next intermediate option is that active support can be included individually gem in an app using another framework.

And finally, if we do eventually want to pursue making decanter framework-agnostic, did you already see this? https://github.com/davydovanton/stop_active_support_anywhere

He has a short bit on the dangers of activesupport in terms of how it's just a big monkey patch, and that yes it is more closely coupled to a specific framework (rails).

I do see some options for the more complex inflector methods: https://github.com/davydovanton/stop_active_support_anywhere#activesupportinflector

I think this would be fun to pursue if we want to head that direction!

[inveterateliterate]

I am now so deep into this guy's repo issues.

[chawes13]

@inveterateliterate I had found that repo but seemingly missed the Inflector section. I agree that it would be a good opportunity to explore what it would take to remove activesupport as a dependency. I'll include that as an initiative for v4