What's left to implement?

[badtuple]

Hello!

Sorry for the super vague issue/question, but I'm currently shopping around for Go implementations of liquid to avoid writing my own. The other implementation I've come across has some structural issues, especially around error handling. Do you have an offhand idea of what's done/to-be-done with this project? Wouldn't mind contributing substantially if it's something I could use in Prod within a few weeks, but that might be alot to ask.

[hownowstephen]

Fantastic to hear! Been intending on picking work back up on it. I started working on this for the same reason - the other implementation didn't quite match up to what I was needing.

I started filing some issues for known outstanding work from the tests/unit section of the original - but haven't started at all on anything outside of those, been kind of growing it from there so far.

As far as I remember, at this point it's capable of parsing templates for the most part, but doesn't have any of the rendering parts written. As it's been quite some time, I don't have a particularly good idea of how far out it is from being anything resembling production-ready, but am thinking I'll spend some time this week getting re-acquainted with it, maybe laying some groundwork for where I see it going, then would love to have some help getting it there 👍

[osteele]

Hey all, just a +1 that I'd eagerly use this too. I'm writing a Jekyll implementation in Go, and a decent Liquid implementation is the missing piece.

I'm currently using JSON-RPC to call a JavaScript implementation (https://github.com/harttle/shopify-liquid), but slows down rendering and complicates the setup instructions.

[ghost]

Super excited about this package! Looking at the open issues and I'm gonna try to grab one and see what I can do. One thing I'm a little curious about is the reworking-node-structure branch...is it worth looking at what you did there in context of any of the open issues? Don't wanna write something based on master and have to scrap it because I didn't forsee where things were going ;)

[osteele]

I ended up writing my own implementation https://github.com/osteele/liquid. You're welcome to use its internal packages in your implementation. For example, Ruby-compatible date formatting, and implementing an evaluator with Ruby semantics (comparing two values, indexing an array, retrieving a property from an object), each ended up being substantial amounts of work. If these aren't learning goals or differentiators for this project, you might want to skip implementing them.

Caveats:

• My library doesn't completely work on Windows. Specifically Strftime implementation (used in the date filter) doesn't report time zones. I don't know whether this is a general problem with time zones, or just with my test suite.
• The internal package APIs aren't stable. (The public interfaces use semver – they are compatible across minor and subminor versions.) If you use them, either fork a copy so you have control over which version you import, or use a dependency manager, such as glide, that allows you to name a specific tag.