Shopify / Shopify/liquid

`blank` and `empty` special keywords are not properly parsed in Liquid 5

Open
#1,566 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
11.9k
Forks
1.5k
Avg merge
17h 55m
Merged PRs (30d)
3

Description

Hey friends,

I was just working on upgrading Jekyll from Liquid v4 to v5. I have everything working except our where filter. We have our own where filter for arcane historical reasons. It works flawlessly in Liquid 5 except in two cases: using empty or blank as the value comparator:

{{ hash | where: "property", empty }}
{{ hash | where: "property", blank }}

We expect these to somewhat behave like Ruby's empty? and Rails's blank? methods, since previously Liquid would pass us the Liquid::Expression::MethodLiteral corresponding to these special keywords. We could then process them specially. Unfortunately, we're now just getting the empty string ("") when we use blank or empty. (https://github.com/jekyll/jekyll/pull/9030#issuecomment-1094510678)

I see that @dylanahsmith (👋) wrote #1300 which changed Liquid::Expression::LITERALS to set empty and blank as "" which could be related to why our filter is getting target = "" instead of target = Liquid::Expression::MethodLiteral<name=:empty? to_s="">.

Is there any way we, as the filter authors, could be notified that the target is the special keyword empty or blank?

Thanks for your hard work on Liquid!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the behavior described around Liquid::Expression::LITERALS and the change in #1300, then trace how the parser passes empty and blank to filters. Compare that with the prior MethodLiteral behavior referenced in the issue and the custom where filter example. Done means filter authors can distinguish these special keywords from an ordinary empty-string comparator, with coverage for both cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.