You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, there's no extension for prettier which would allow it to prettify twig/melody templates.
All the reasons for why it makes sense to use prettier also apply for why Melody should be supported by it.
Expected behaviour
When I run prettier on a Melody file, it prettifies the template. It should also work regardless of which Melody plugins I am using (even if they introduce new AST nodes).
Hint for a solution
The Melody compiler is generally built to facilitate an external traversal strategy. However, for a tool like prettier that'd not work. The prettier plugin would have to include every existing Melody plugin or would itself need to be extensible through plugins (meaning you'd create plugins for a plugin).
Instead, I'd suggest to directly add it to Melodys Node class (https://github.com/trivago/melody/blob/master/packages/melody-types/src/index.js#L25) and to provide specializations for each and every node within Melody. Plugins will need to be updated to support prettier as well.
That way, going forward prettier will be a first class citizen and new language features will include a discussion on their formatting rules right away.
We'd have two options with respect to the release containing this:
a) We accept that its a breaking release and name it 2.0
b) We architect the solution in a way that will cause the prettier run to fail (with a nice error message) when a Node doesn't support prettification (breaking the prettier plugin) and are free to name it 1.x. At the point when we do create the 2.0 release, we'd be able to drop compatibility and require prettier support on node level for all plugins.
I'd prefer option b.
The text was updated successfully, but these errors were encountered:
Explain the problem
At the moment, there's no extension for prettier which would allow it to prettify twig/melody templates.
All the reasons for why it makes sense to use prettier also apply for why Melody should be supported by it.
Expected behaviour
When I run prettier on a Melody file, it prettifies the template. It should also work regardless of which Melody plugins I am using (even if they introduce new AST nodes).
Hint for a solution
The Melody compiler is generally built to facilitate an external traversal strategy. However, for a tool like prettier that'd not work. The prettier plugin would have to include every existing Melody plugin or would itself need to be extensible through plugins (meaning you'd create plugins for a plugin).
Instead, I'd suggest to directly add it to Melodys Node class (https://github.com/trivago/melody/blob/master/packages/melody-types/src/index.js#L25) and to provide specializations for each and every node within Melody. Plugins will need to be updated to support prettier as well.
That way, going forward prettier will be a first class citizen and new language features will include a discussion on their formatting rules right away.
We'd have two options with respect to the release containing this:
a) We accept that its a breaking release and name it 2.0
b) We architect the solution in a way that will cause the prettier run to fail (with a nice error message) when a Node doesn't support prettification (breaking the prettier plugin) and are free to name it 1.x. At the point when we do create the 2.0 release, we'd be able to drop compatibility and require prettier support on node level for all plugins.
I'd prefer option b.
The text was updated successfully, but these errors were encountered: