Improve this `unpipe` function?

Is the idea here to unpipe everything next/down from the current zipper? I think your code would turn this

socket
|> assign(:foo, "foo" |> String.trim())

into this:

assign(socket, :foo, String.trim("foo"))

Is that what you’re aiming for?

Yes, any single pipes, though that particular case I did not account for! It does indeed work here though it adds new lines (which is a separate general issue I’m dealing with).

These were my test cases so far (not super thorough):

defp run(string, func) do
  result =
    string
    |> Sourceror.parse_string!()
    |> func.()
    |> Sourceror.to_string()

  result <> "\n"
end

describe "unpipe" do
  test "changes single pipes into inline calls" do
    source = ~S"""
    socket
    |> assign(:foo, "foo")
    """

    result = run(source, &unpipe/1)

    assert result == ~S"""
           assign(socket, :foo, "foo")
           """
  end

  test "leaves longer pipelines alone" do
    source = ~S"""
    socket
    |> assign(:foo, "foo")
    |> assign(:bar, "bar")
    """

    result = run(source, &unpipe/1)

    assert result == ~S"""
           socket
           |> assign(:foo, "foo")
           |> assign(:bar, "bar")
           """
  end

  test "handles nested pipes" do
    source = ~S"""
    foo
    |> bar()
    |> baz(fn n ->
      n
      |> bar()
      |> baz(fn m ->
        m
        |> foo()
      end)
    end)
    """

    result = run(source, &unpipe/1)

    assert result == ~S"""
           foo
           |> bar()
           |> baz(fn n ->
             n
             |> bar()
             |> baz(fn m ->
               foo(m)
             end)
           end)
           """
  end

Ahhh, interesting. Only pipes where there isn’t a 2 or more pipes. Neat idea In that case your traverse + prev/next strategy looks like the best way to go about this IMO. It’s a benefit of Zipper that you actually don’t need an accumulator to do this kind of thing. It would only add complexity IMO.

The new line change likely is just coming from the fact that the code is formatted when you stringify it? Probably nothing to be done there?

Yes, I just started on a new team that inherited a codebase where it’s rampant. I’m not too fussed about “no single pipes” depending on how they are used, but they are everywhere to point it’s making code exhausting to read. There is even stuff like this:

"string"
|> String.capitalize()

In any event, we’re getting all of our bikeshedding out of the way upfront And it’s also nice to have a task to run in CI.

That’s good to know! Zipper certainly allowed me to write code inline with how I was thinking about the problem. It’s more of an academic interest if it’s even possible with basic walking as it was hurting my brain trying to figure it out. I’m happy to move on from it, though.

The problem is is that it’s doing it for any function calls that have more than one arg, even if the line is within the limit. I believe it has to do with how Sourceror adds :__block__ around stuff to help maintain the original format. I’m pretty sure I just need to be more explicit in how I return the transformed node. I believe the answer might be in here somewhere.

Thanks for your response, Zach!

Ah, right. I think what you can do is check if the node previous to the top node is {:__block__, meta, [just_one_thing]} and if so, replace that node instead? Might mess w/ your traversal though.

Ok, I may be celebrating early but simply setting empty meta solved it.

       {:|>, _, [var, {func, _, args}]} <- node do
    Sourceror.Zipper.replace(zipper, {func, [], [var | args]})

I’ll keep an eye out for this, thanks!!

Turns out the real answer is “just use recode” which I totally forgot about. Was a good learning experience regardless

Based on your proclivity for source code rewriting, you may also be interested in the igniter project

It’s similar to recode in some ways, but designed for building generators, installers, and upgraders. GitHub - ash-project/igniter: A code generation and project patching framework. · GitHub