Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate prettier printing #67

Open
pago opened this issue Oct 2, 2018 · 0 comments
Open

Integrate prettier printing #67

pago opened this issue Oct 2, 2018 · 0 comments
Assignees

Comments

@pago
Copy link
Contributor

pago commented Oct 2, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants