Open SamSaffron opened 6 years ago
I have another example of unexpected heredoc formatting that I think is definitely not desired behavior:
expect(
course_type.resolve(<<~GQL, current_user: @student)
assignmentsConnection(filter: {gradingPeriodId: null}) { edges { node { _id } } }
GQL
).to match course.assignments.published.map(&:to_param)
becomes
expect(
course_type.resolve(<<~GQL, current_user: @student)
assignmentsConnection(filter: {gradingPeriodId: null}) { edges { node { _id } } }
GQL
········
).to match course.assignments.published.map(&:to_param)
(the ········
in this case is whitespace that rufo is introducing for whatever reason).
Rufo will format HEREDOCs invalidly too, e.g.
Turn this valid, and in my opinion, correctly formatted HEREDOC
execute (<<-SQL).gsub(/\n\s+/, " ")
# Some complex SQL migration thats being dedented
SQL
Into
execute (<<-SQL
).gsub(/\n\s+/, " ")
# Some complex SQL migration thats being dedented
SQL
After it's done this it will then be unable to parse the file again, as it's now not valid Ruby.
Rufo somehow added very long lines of spaces for some my heredoc strings (and has completely broken tilda heredocs contents with that).
FWIW I noticed that it will keep adding more indentation each time rufo is run. In other words it doesn't get to a stable formatting. This is with the latest version of rufo at the time of writing this (0.7.0).
I created a new issue #188 specifically for the rowing whitespace issue
Is aligned:
Which is somewhat odd... it aligns as expected for
DB.exec(<<~SQL)
Note, now the we adopted Prettier for Discourse js I am very very keen to move to rufo, from my tests on a few files this appears to be the biggest point of contention, there is some around params as well cause our rubocop rules currently are at odds with what rufo produces.