V3 Release

[gjtorikian]

Mostly, this will modernize the gem by dropping old Ruby and Rails implementations. I'm also planning to user kwargs across the filters and methods.

If you're reading this and looking forward to adding a new breaking change, please open an issue to discuss.

Merged PRs for a future changelog:

• Switch to GitHub Actions #346 (drop unnecessary ActiveSupport usage, drop Ruby support < 2.5)
• Add Rubocop #349
  • Set up kwargs for context and result
  • Remove deprecated whitelist naming
  • Drop CamoFilter, EmailReplyFilter, TextileFilter as they are either GitHub specific or just plain outdated
• Support multiple dependencies per filter #351
  • Support for multiple dependencies
• Split filters up #360
• Migrate to Selma Migrate from Nokogiri to Selma #368

[digitalmoksha]

Can you upstream this to here? AssetProxyFilter looks much nicer.

Yeah you bet!

[gjtorikian]

Can you upstream this to here? AssetProxyFilter looks much nicer.

Yeah you bet!

Hey, any interest in upstreaming?

[digitalmoksha]

Yeah of course, sorry I spaced on this. Let me spin something up...

Edit: spun up #379

[digitalmoksha]

@gjtorikian I'm curious, have you considered creating a Rust version of html-pipeline? I'm thinking about moving some of our filters into a Rust based pipeline for speed 🤔

[gjtorikian]

I haven't thought about it—but walk me through which part you would want/expect to Rustify ? All I do these days is wrap Rust in Ruby. 😆

V3 moved the bulk of the HTML selection-manipulation logic to using selma, which uses lol-html under the hood. html-pipeline is now just a dumb interface which takes an array of Ruby classes and iterates over their selectors; but the real manipulation work is done in Rust, and the Ruby class just acts as a sort of sugar on top. If anything, I'd like to move towards turning this into an async library (which is partly why I haven't solidified v3 yet--haven't had time to explore what this would entail).

[digitalmoksha]

I think it would be basically the same as what you have now, just in Rust - given a vector of filters, run through them calling their transformation function, passing results from one to the other.

Still coming up to speed on Rust's object oriented features, but it seems like using traits might give you the ability to not only gain default functionality of say a TextFilter, but allow you to override that functionality as well.

So if we have our own Rust crate which we can move some of our current Ruby filters/pipeline into, then I think we would see some performance win.

Haven't yet attempted to migrate to V3 of html-pipeline, so maybe that would be enough of a win. But I'm still considering having some type of pipeline ability in our Rust crate.

So I thought you might have something in the works ;-)