First/Last of a string

[microalps]

In reviewing golden liquid tests, we find that two rules are not necessarily true. It depends on whether it is running within rails, active support is included, or plain ruby is being used (as your tests do).

  def test_string_first_last
    nativedata = { 'str' => 'hello' }
    assert_equal 'h', Liquid::Template.parse('{{ str | first }}', error_mode: :strict).render(nativedata)
    assert_equal 'h', Liquid::Template.parse('{{ str.first }}', error_mode: :strict).render(nativedata)
    assert_equal 'o', Liquid::Template.parse('{{ str | last }}', error_mode: :strict).render(nativedata)
    assert_equal 'o', Liquid::Template.parse('{{ str.last }}', error_mode: :strict).render(nativedata)
  end

These tests will pass if you add require 'active_support/all' to your declaration.

[jg-rp]

Hi @microalps,

Very true. @sebastienros noticed the same thing here and here.

We could add a flag to test cases where the result is dependant on the environment, and/or an array of acceptable results instead of a single expected result where it makes sense.

[microalps]

Array of acceptable responses is an interesting idea, but then who gets to vote what is acceptable or not? For example, newline_to_br in the Liquid implementation replaces \r\n with <br />\n (and drops the \r). DotLiquid only prepends the <br /> and maintains the \r\n if that is what the user had to begin with. Some other implementation might use <br/> which is also not wrong. This is a simple example, but it becomes hard to come to consensus with implementors on every alternative.

In DotLiquid, we chose to override the "want" value in a separate ruleset for tests that we consider passing even though it's not bug for bug with Shopify. You noted in the README about LiquidJS "... and its lack of distinct float and int types." which might benefit if we agree on when alternates are acceptable.

[jg-rp]

This repository will always follow Shopify/liquid's main branch. A results array would be strictly for results that change depending on how Shopify/liquid is deployed. But you're right, it would still be a judgement call as to what deployment configurations are considered acceptable.

I've started a separate compliance test suite for the imaginatively named Liquid2. It deliberately deviates from Shopify/liquid, fixing bugs and adding features.

Having a Liquid specification with accompanying test suite that we all agree on would be great, but would take years of debate and work to do it properly, so my expectations are quite low.