Skip to content
This repository has been archived by the owner on Sep 5, 2020. It is now read-only.

Add Support for soy #21

Closed
jbalsas opened this issue Nov 27, 2017 · 9 comments
Closed

Add Support for soy #21

jbalsas opened this issue Nov 27, 2017 · 9 comments

Comments

@jbalsas
Copy link
Contributor

jbalsas commented Nov 27, 2017

We have a tool that can be used to lint *.soy files. Ideally, it should be integrated here:

https://github.com/metal/metal-soy-critic

@natecavanaugh
Copy link
Contributor

@jbalsas I think this could be interesting, but one quick question is basically, is the soy linting tool part of the metal-soy-critic component, or you're saying that it should be incorporated?

If we have the tool, can you point me to it?

@jbalsas
Copy link
Contributor Author

jbalsas commented Dec 11, 2017

Hey @natecavanaugh, metal-soy-critic IS the linting tool 😉

@jbalsas
Copy link
Contributor Author

jbalsas commented Dec 11, 2017

This pending issue about library usage might be important to integrate it here the way this tool is built, I guess

@natecavanaugh
Copy link
Contributor

@jbalsas Ahhh gotcha, okay.

My one concern would be about cases where people use Soy but without Metal (which is still prominent), but here are a few other questions:

I'm guessing this isn't so much about linting Soy, as it is about linting Soy based metal components?
Looking over the tests, it seems like it's more of a general linter, but not sure about the metal integration, or if it even checks metal components.

But yeah, if this is just for general soy language linting, I can definitely integrate that as a soy specific formatter.

Let me know if my assumptions are correct, and I'll go ahead and work on integrating it once you guys have some sort of non-cli API exported :)

@mthadley
Copy link

So it wasn't originally written as a general .soy linter. From the README:

A utility for validating your metal-soy components. This tool is not meant to do the same work that your javascript or soy compiler already does. Instead it checks for anti-patterns in your components.

However, now there are definitely some lint rules in metal-soy-critic that are only for Soy and are actually unrelated to Metal. Maybe it would also be worth it to separate those rules somehow as part of the API for metal-soy-critic?

@natecavanaugh
Copy link
Contributor

@mthadley I could definitely see it being a possibility, but now my other question would be, are there are good heuristics for when to apply just general soy linting, or if it's actually a metal based soy file?

@mthadley
Copy link

@natecavanaugh The only heuristic right now is if there is a file in the same directory, with the same filename, but with a .js extension. So if that file exists, it lints it as a Metal component. We could also add some configuration that changes how this works, though.

@jbalsas
Copy link
Contributor Author

jbalsas commented Dec 12, 2017

Hey guys, I think this is a bit of an overkill right now. metal-soy-critic lints the way we are expected to use soy in Liferay. We can definitely annotate the rules, and get fancier, but I'd prefer to see real usage first and then draw from experience.

@wincent
Copy link
Contributor

wincent commented Sep 4, 2020

We're going to be archiving this project so closing everything.

@wincent wincent closed this as completed Sep 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants