Upgrade to Liquid v4

[parkr]

RC1 for now.

@fw42 @dylanahsmith, know what's going on here? .parse isn't working like before.

Error:
TestTags#test_: highlight tag in unsafe mode should recognize the hl_linenos option and its value. :
NoMethodError: undefined method `line_number' for {}:Hash
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/liquid-4.0.0.rc1/lib/liquid/tag.rb:21:in `initialize'
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/liquid-4.0.0.rc1/lib/liquid/block.rb:4:in `initialize'
    /Users/parkr/jekyll/jekyll/lib/jekyll/tags/highlight.rb:14:in `initialize'
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/liquid-4.0.0.rc1/lib/liquid/tag.rb:9:in `new'
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/liquid-4.0.0.rc1/lib/liquid/tag.rb:9:in `parse'
    test/test_tags.rb:46:in `highlight_block_with_opts'
    test/test_tags.rb:92:in `block (2 levels) in <class:TestTags>'
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/shoulda-context-1.2.1/lib/shoulda/context/context.rb:413:in `instance_exec'
    /Users/parkr/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/shoulda-context-1.2.1/lib/shoulda/context/context.rb:413:in `block in create_test_from_should_hash'

[dylanahsmith]

jekyll/test/test_tags.rb

Line 46 in 281f751

Jekyll::Tags::HighlightBlock.parse('highlight', options_string, ["test", "{% endhighlight %}", "\n"], {})

passes in a list of tokens into a Tag, but we now use a tokenizer which also keeps track of the current line number during parsing.

This could be worked around by using Liquid::Tokenizer.new("test{% endhighlight %}\n"), but the tests would still be brittle to internal liquid changes, so it is recommended to parse a complete template using Liquid::Template rather than constructing individual tags with mocked out data.

[dylanahsmith]

jekyll/test/test_tags.rb

Line 46 in 281f751

Jekyll::Tags::HighlightBlock.parse('highlight', options_string, ["test", "{% endhighlight %}", "\n"], {})

passes in a list of tokens into a Tag, but we now use a tokenizer which also keeps track of the current line number during parsing.

This could be worked around by using Liquid::Tokenizer.new("test{% endhighlight %}\n"), but the tests would still be brittle to internal liquid changes, so it is recommended to parse a complete template using Liquid::Template rather than constructing individual tags with mocked out data.

[envygeeks]

Would this affect normal everyday plugins @dylanahsmith ?

[envygeeks]

Would this affect normal everyday plugins @dylanahsmith ?

[parkr]

it is recommended to parse a complete template using Liquid::Template rather than constructing individual tags with mocked out data.

👍

Would this affect normal everyday plugins

This looks like it's only in our tests where this is going to be an issue. Most plugins don't use this Tag.parse method directly, I think only our tests do that.

[parkr]

it is recommended to parse a complete template using Liquid::Template rather than constructing individual tags with mocked out data.

👍

Would this affect normal everyday plugins

This looks like it's only in our tests where this is going to be an issue. Most plugins don't use this Tag.parse method directly, I think only our tests do that.

[parkr]

@dylanahsmith Our tests depend on having access to the instance created. I gave it a shot with Liquid::Template.parse but gave up after about 30 minutes of looking through the Liquid code.

It looks like v4 works (CI works fine for me locally). Would you consider releasing a new version soon and we can upgrade?

[parkr]

@dylanahsmith Our tests depend on having access to the instance created. I gave it a shot with Liquid::Template.parse but gave up after about 30 minutes of looking through the Liquid code.

It looks like v4 works (CI works fine for me locally). Would you consider releasing a new version soon and we can upgrade?

[parkr]

@dylanahsmith @fw42 @pushrax Hi! Would it be possible to reconsider a 4.0 release? Especially keen to get the whitespace change out to our users. Thanks!

[parkr]

@dylanahsmith @fw42 @pushrax Hi! Would it be possible to reconsider a 4.0 release? Especially keen to get the whitespace change out to our users. Thanks!

[fw42]

I'm ok with releasing a new version of Liquid. As far as I know, there isn't any pending non-backwards compatible changes that we want to get in before a new release. @pushrax @dylanahsmith, thoughts?

[fw42]

I'm ok with releasing a new version of Liquid. As far as I know, there isn't any pending non-backwards compatible changes that we want to get in before a new release. @pushrax @dylanahsmith, thoughts?

[dylanahsmith]

version ⬆️ 👍

[dylanahsmith]

version ⬆️ 👍

[pushrax]

Also 🆗 from me

[pushrax]

Also 🆗 from me

[DirtyF]

🎉 https://github.com/Shopify/liquid/releases/tag/v4.0.0.rc3

[DirtyF]

🎉 https://github.com/Shopify/liquid/releases/tag/v4.0.0.rc3

[fw42]

Yea I just released 4.0rc versions of both Liquid and Liquid-C. @parkr, can you see if everything works on your end? If so, I can release a real non-rc release.

[fw42]

Yea I just released 4.0rc versions of both Liquid and Liquid-C. @parkr, can you see if everything works on your end? If so, I can release a real non-rc release.

[parkr]

Interesting –– all of our where_exp tests fail.

[parkr]

Interesting –– all of our where_exp tests fail.

[parkr]

Looks like things are working here. I'd be interested in getting this into a v3.4, though I have concerns about what incompatibilities for plugin authors.

[parkr]

Looks like things are working here. I'd be interested in getting this into a v3.4, though I have concerns about what incompatibilities for plugin authors.

[Crunch09]

@parkr I think the only public API thing we changed was to add Jekyll::Drop::SiteDrop#key?. Do you know of any liquid-related plugins so we could check them out before?

Also if you think we're ok, we could give @fw42 a go to release 4.0 non-rc 🎆

[Crunch09]

@parkr I think the only public API thing we changed was to add Jekyll::Drop::SiteDrop#key?. Do you know of any liquid-related plugins so we could check them out before?

Also if you think we're ok, we could give @fw42 a go to release 4.0 non-rc 🎆

[parkr]

@fw42 If this CI passes, then feel free to release v4.0 of Liquid. ❤️

[parkr]

@fw42 If this CI passes, then feel free to release v4.0 of Liquid. ❤️

[fw42]

We have a few last minute breaking changes that we want to get in, but I will try to release v4 this week if possible.

[fw42]

We have a few last minute breaking changes that we want to get in, but I will try to release v4 this week if possible.

[parkr]

@fw42 More Breaking changes may mean we can't upgrade 😦 Would it be possible to release a 5.0 with those changes? We may be stuck on 3.x if we can't guarantee compatibility at the high level for plugins. Or, perhaps we can run our test suite against the individual pull requests?

[parkr]

@fw42 More Breaking changes may mean we can't upgrade 😦 Would it be possible to release a 5.0 with those changes? We may be stuck on 3.x if we can't guarantee compatibility at the high level for plugins. Or, perhaps we can run our test suite against the individual pull requests?

[dylanahsmith]

@parkr Shopify/liquid#835 is the change that I would like to get into liquid v4, since it provides a more secure default for rendering errors, so that sensitive information doesn't get leaked through the error message. I tried running the tests on this jekyll branch against that liquid branch and everything passed. It looks like jekyll uses Liquid::Template#render!, which isn't affected by that pull request, since it will continue to re-raise the exception as it did before.

[dylanahsmith]

@parkr Shopify/liquid#835 is the change that I would like to get into liquid v4, since it provides a more secure default for rendering errors, so that sensitive information doesn't get leaked through the error message. I tried running the tests on this jekyll branch against that liquid branch and everything passed. It looks like jekyll uses Liquid::Template#render!, which isn't affected by that pull request, since it will continue to re-raise the exception as it did before.

[parkr]

@dylanahsmith Perfect, thank you!

[parkr]

@dylanahsmith Perfect, thank you!

[envygeeks]

Yay for Liquid 4.

[envygeeks]

Yay for Liquid 4.

[ashmaroli]

Liquid 4 is now officially here 🎉
ad00998

[ashmaroli]

Liquid 4 is now officially here 🎉
ad00998

[pathawks]

I don't think I'll have time to put Liquid 4 through it's paces for another week or so, but I am super excited for some of the new features it brings!

[pathawks]

I don't think I'll have time to put Liquid 4 through it's paces for another week or so, but I am super excited for some of the new features it brings!

[ashmaroli]

I wonder why tests suddenly fail when they had passed with v4.0.0.rc3

[ashmaroli]

I wonder why tests suddenly fail when they had passed with v4.0.0.rc3

[fw42]

Test failures look related to Shopify/liquid#835 or Shopify/liquid#837.

[fw42]

Test failures look related to Shopify/liquid#835 or Shopify/liquid#837.

[fw42]

Probably the latter since @dylanahsmith said that he tested the former with this branch.

[fw42]

Probably the latter since @dylanahsmith said that he tested the former with this branch.

[pushrax]

Oh god, working around Liquid's lack of expressions with strings 😭

We (@gmalette, @sgnr) have been talking a bit about how to add proper expression support to Liquid. I think we can do it in 2017.

[pushrax]

Oh god, working around Liquid's lack of expressions with strings 😭

We (@gmalette, @sgnr) have been talking a bit about how to add proper expression support to Liquid. I think we can do it in 2017.

[parkr]

Having a Liquid::Variable.parse class method would make it more consistent with Liquid::Template and tags classes

@dylanahsmith I like that idea. I think we're fairly comfortable breaking the rules a bit for now since there aren't tons of releases of Liquid and y'all are very kind about helping us test our code when you do want to make updates. Having Liquid::Variable.parse that offers a stable external API would be preferable, of course, but we're aware that our use of Liquid is not really your primary development concern.

Is there a way for us to make our current usage line up better with how it should work, e.g. by passing the proper Liquid::ParseContext from the parent template?

[parkr]

Having a Liquid::Variable.parse class method would make it more consistent with Liquid::Template and tags classes

@dylanahsmith I like that idea. I think we're fairly comfortable breaking the rules a bit for now since there aren't tons of releases of Liquid and y'all are very kind about helping us test our code when you do want to make updates. Having Liquid::Variable.parse that offers a stable external API would be preferable, of course, but we're aware that our use of Liquid is not really your primary development concern.

Is there a way for us to make our current usage line up better with how it should work, e.g. by passing the proper Liquid::ParseContext from the parent template?

[parkr]

Well, I have certainly sullied up this branch. Let's see if I can fix that git history...

[parkr]

Well, I have certainly sullied up this branch. Let's see if I can fix that git history...

[pathawks]

❤️

Doesn't break any jekyll/* plugins 👍

[JamesDrummond]

When will this PR be merged? Patiently waiting for liquid 4.0 features ;) . Also I was trying to find where you list when the next release and ship date is planned for.

[JamesDrummond]

When will this PR be merged? Patiently waiting for liquid 4.0 features ;) . Also I was trying to find where you list when the next release and ship date is planned for.

[parkr]

I think we'll try to ship a 3.4 this week, with a 3.5 a bit after that.

[parkr]

I think we'll try to ship a 3.4 this week, with a 3.5 a bit after that.

[parkr]

Fixes #5772.

[parkr]

Fixes #5772.

[keslert]

Any update on this? Waiting not quite as patiently as @JamesDrummond ;).

[keslert]

Any update on this? Waiting not quite as patiently as @JamesDrummond ;).

[Crunch09]

@keslert It is planned to be released in jekyll 3.5. Jekyll 3.4 should be out this week, so it probably will be merged in afterwards.

[Crunch09]

@keslert It is planned to be released in jekyll 3.5. Jekyll 3.4 should be out this week, so it probably will be merged in afterwards.

[parkr]

@jekyllbot: merge +minor

[parkr]

@jekyllbot: merge +minor