Generator-jhipster: Study using Prettier to format generated code

[jdubois]

We spend a lot of time to generate well-formatted code.

Prettier is a source code formatter, available as a Node module: it should be very easy to send our generated code to Prettier before writing the file, so that the end-result is perfectly formatted by Prettier.

In the end, we would win a lot of time: no need to worry anymore about formatting everything so that the end-result is good. We could focus on having some clean code inside the template, instead. Too often, our templates are unreadable because of the output we want to have.

This is also the only solution for things like import statements, as we don't know what the user will do (for example, what name will he use for his entities).

Unfortunately, Prettier doesn't support Java, so this would only work for TypeScript:

• We need a JavaScript tool, so that it works in our generation pipeline - we can't use Java-based code formatters
• TypeScript is already quite a lot of code, so that's a good starting point
• Maybe we could write the Java support for Prettier? I could try to find a trainee for that

[deepu105]

Yes we should use it

Thanks & Regards,
Deepu

On Tue, Sep 19, 2017 at 1:59 PM, Julien Dubois [e-mail]
wrote:

We spend a lot of time to generate well-formatted code.

Prettier https://github.com/prettier/prettier is a source code
formatter, available as a Node module: it should be very easy to send our
generated code to Prettier before writing the file, so that the end-result
is perfectly formatted by Prettier.

In the end, we would win a lot of time: no need to worry anymore about
formatting everything so that the end-result is good. We could focus on
having some clean code inside the template, instead. Too often, our
templates are unreadable because of the output we want to have.

This is also the only solution for things like import statements, as we
don't know what the user will do (for example, what name will he use for
his entities).

Unfortunately, Prettier doesn't support Java, so this would only work for
TypeScript:

• We need a JavaScript tool, so that it works in our generation
  pipeline - we can't use Java-based code formatters
• TypeScript is already quite a lot of code, so that's a good starting
  point
• Maybe we could write the Java support for Prettier? I could try to
  find a trainee for that

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/6379, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABDlF6bae5L0xO-RRz1STWDOwuKKRuxTks5sj6yHgaJpZM4PcR96
.

[deepu105]

We could also explore what VSCode plugins uses for formatting as some of
the plugins support java, js and Ts

Thanks & Regards,
Deepu

On Tue, Sep 19, 2017 at 2:31 PM, Deepu K Sasidharan <
[email protected]> wrote:

Yes we should use it

Thanks & Regards,
Deepu

On Tue, Sep 19, 2017 at 1:59 PM, Julien Dubois [e-mail]
wrote:

We spend a lot of time to generate well-formatted code.

Prettier https://github.com/prettier/prettier is a source code
formatter, available as a Node module: it should be very easy to send our
generated code to Prettier before writing the file, so that the end-result
is perfectly formatted by Prettier.

In the end, we would win a lot of time: no need to worry anymore about
formatting everything so that the end-result is good. We could focus on
having some clean code inside the template, instead. Too often, our
templates are unreadable because of the output we want to have.

This is also the only solution for things like import statements, as we
don't know what the user will do (for example, what name will he use for
his entities).

Unfortunately, Prettier doesn't support Java, so this would only work for
TypeScript:

• We need a JavaScript tool, so that it works in our generation
  pipeline - we can't use Java-based code formatters
• TypeScript is already quite a lot of code, so that's a good
  starting point
• Maybe we could write the Java support for Prettier? I could try to
  find a trainee for that

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/6379, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABDlF6bae5L0xO-RRz1STWDOwuKKRuxTks5sj6yHgaJpZM4PcR96
.

[PierreBesson]

Great idea to format code at generation time !

Note : code formatters for Java already exist:

• https://github.com/google/google-java-format (doesn't suit me)
• Also you can use both the Eclipse and IntelliJ code formatters from the command line (requires an installation of the respective IDE).

[gmarziou]

Why don't you like google-java-format ?
It seems to be easy to use from both maven and gradle, so we could easily run it after project generation.

Anyway, the problem with these tools is that it's ok to run them on code we generate which is easy when you generate an app but how would you run them only on the files generated by the entity generator?

[PierreBesson]

@gmarziou I'm not a big fan of google-java-format coding style (personal habits) and it can not be customized at all :disappointed:.

@gmarziou I think the idea was not to run this after generation but somehow during the generation itself (so the generated files are correctly formatted out of the box).

[jdubois]

@gmarziou @PierreBesson we need an NPM-based tool, so we can integrate it into our generation pipeline: files should be "prettified" before being written. That's way faster, and a lot easier to integrate.

[deepu105]

Found a NPM lib that can format java
https://www.npmjs.com/package/auto-format

[deepu105]

This is also best use case for using the piping feature in Yeoman
http://yeoman.io/authoring/file-system.html

[jdubois]

Yes @deepu105 that's my goal

[deepu105]

We could also write an import organiser that follows the IntelliJ default, this will help us simplify our templates further

[deepu105]

Probabaly we could use this https://www.npmjs.com/package/gulp-format

[deepu105]

Since it uses CLang we could use it to format JS, Ts, Java and may be even XML etc

[gmarziou]

First time I hear about CLang. gulp-format packages 8 MB of clang-format binaries for 4 platforms: 2 linux and 2 windows, no mac. Do you plan to maintain such an npm module or to require users to have clang-format already installed?

[jdubois]

And Prettier should do a much better job than CLang, really

[deepu105]

@gmarziou I didnt know you had to install binaries for CLang as I havent used it myself and found it when searching for a Java formatter package on NPM

[deepu105]

In that case may be we can use prettier for JS/TS/CSS and https://github.com/jundl77/auto-format for Java

[jdubois]

Java support is the only issue, I'm trying to get a trainee who could work on this

[PierreBesson]

@jdubois, if such a tool were to be made by a trainee I would suggest considering to do it in Java and basing it on intellij open source code (https://github.com/JetBrains/intellij-community/tree/master/platform/lang-impl/src/com/intellij/formatting) or Eclipse. Then this can be packaged as a jar and run from yeoman.
Too bad Intellij is not build with maven. It is actually build using Intellij itself which is crazy !

Anyway we can delay Java support for now.

[deepu105]

@PierreBesson that would mean our generator will become too complex to use and would make JVM a dependency to run along with NodeJS. I don't like mixing JVM with node apps personally.
I believe if it can be made in java it can be made in JS as well. And this lib is doing it https://github.com/jundl77/auto-format so we could base something on that to start with

[jdubois]

I'm pretty sure @SBoudrias is following us this discussion :-)
See https://github.com/yeoman/generator-node/releases/tag/v2.3.0

[jdubois]

I've studied this in a bit more details as I need this for my current client: it's basically not possible to support Java with Prettier, unless you do a huge work of course.

So here's my current plan for this:

• [ ] Add Prettier for all front-end code: this is very easy and would be a good first PR if anyone wants to try it
• [ ] For the Java code, add net.revelc.code:formatter-maven-plugin to format the code with Maven (need to check if there is the same with Gradle). As this doesn't seem to optimize Java imports, it's not going be a huge help (I ran it on the sample project and it didn't optimize any imports - and I'd be very surprized that we have no issue here). In fact, it might make some of our code less readable...

[atomfrede]

@jdubois I have just found https://github.com/diffplug/spotless It looks quite feature rich. Need to see if I find some time to test it (it also has a maven plugin, not sure if all features are support though)

[deepu105]

It looks cool but the Maven plugin doesn't have all features but probably
we can help them with that

Thanks & Regards,
Deepu

On Tue, Nov 14, 2017 at 5:00 PM, Frederik Hahne [e-mail]
wrote:

@jdubois https://github.com/jdubois I have just found
https://github.com/diffplug/spotless It looks quite feature rich. Need to
see if I find some time to test it (it also has a maven plugin, not sure if
all features are support though)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/6379#issuecomment-344305455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFyx-ibEqc7PnlPxlDC9OWWxh7O-nks5s2bkYgaJpZM4PcR96
.

[atomfrede]

Yes Seen it maven plugin does not exist yet. But as it uses the eclipse formatter we could use the plugin suggested by @jdubois I think.

[PierreBesson]

Spotless looks interesting as it can be used both for linting initial code generation and be continuously run on code changes (with a precommit hook) using maven/gradle. Well, the plugin is not currently available but it is planned...
For me the fact that the tool is written in java is not really a problem as we can easily execute jar files from the generator. Using something like npm/find-java-home will ease the job for supporting all OSes. Also I think we can safely assume that the users will have java installed.

[atomfrede]

@jhipster/developers I have tried spotless with a sample app. It looks quite nice as it removes unused imports during build. One problem I see currently is that it will be not easy to define import order such that it matches the ide configuration (but maybe thats a feature we don't enable out of box). Quite nice is also to fail the build if some formatting is not valid. You can have a look at the results here: https://github.com/atomfrede/jhipsterSpotlessSample/pull/1

So I would like to add it to our gradle build (or can create a simple module if we don't want it in the main generator).

[PierreBesson]

@atomfrede Spotless looks cool but I'm not sure if it's so great to fail the build for formatting. The idea of Prettier is to be non intrusive. On the front end we already have formatting warnings, so it would be logical to also have them on the back-end. Is it possible to set it up this way ? Ideally it would be great if we could send notifications on formatting errors like we do with tslint.

[atomfrede]

I can try that.

[jdubois]

Just to let you know: there are 2 persons at Ippon (next to me) who are working on adding Prettier to our Angular build. It's in fact more complex than expected, so give them a few days to finish.

[deepu105]

@atomfrede check this https://github.com/thorbenvh8/prettier-java

[jdubois]

@deepu105 WAT? Prettier in Java? That would be super awesome if we could have prettier for both the front-end and the back-end, I didn't think that was possible! cc @thorbenvh8

[thorbenvh8]

Yes I'm working on this, currently stuck on the parser, but seems like there is a solution!
Can give more feedback after the weekend :)

[jdubois]

@thorbenvh8 we can probably give you some help -> maybe some people from the JHipster community would be interested - I can ask for help on Twitter, do you have a Twitter handle?

[thorbenvh8]

Can we do that after the weekend please? :)
I would love that, but please after. For the current changes to make it is not really possible to work on this shared.

[jdubois]

Yes of course!

[deepu105]

ping @MathieuAA you may be interested as @thorbenvh8 is using PegJS for the Java syntax parsing

[thorbenvh8]

I'm currently trying to switch to Antlr or even write my own parser

[jdubois]

Then you should definitely talk with Mathieu before! He did our JDL parser and knows this very well.

[deepu105]

@thorbenvh8 did you consider the Java Language server used by VScode?
https://github.com/redhat-developer/vscode-java
Not sure how or if it can be used

[deepu105]

@jdubois for JDL we are switching to chevrotain

[jdubois]

Yes and Mathieu seems to like it a lot more than pegjs, that's why his feedback is important

[MathieuAA]

@thorbenvh8 Before you switch to Antlr, I suggest you try chevrotain. It gives you more freedom over the parsing system (you get to decide how each part behaves), you can actually test your system (which is really nice) and it's in JS (well, TS, but it's the same). There are some issues however:

• it takes time to get to know how to use everything
• some parts that you'll write are very likely to seem redundant to you (you have to write the mapping definition for each token yourself for instance)
• PegJS is way easier (but limited if your grammar is complex)

There's a branch in the JHipster Core repo called 'chevrotain-migration', if you want a glimpse of what can be done. It's not over yet and migrating an existing system takes more time than writing one from scratch (that's why it isn't updated until v2.0.0).

[thorbenvh8]

@MathieuAA Wow thank you so much! Building your own will take longer than already using an already existing grammar.

But since I have to update the grammar anyway because I need the comments in AST.
Especially being able to test and having a diagram generated for you, will make upgrading so much easier!

I will start working on this in the next weeks!

[thorbenvh8]

@MathieuAA did you decide for embedded actions or visitor?

[MathieuAA]

I believe chevrotain uses a model based on visitors.

[thorbenvh8]

@MathieuAA https://github.com/SAP/chevrotain/issues/643 how would you solve this with your experience?

[MathieuAA]

Depends, which problem?

[thorbenvh8]

worked on this the whole weekend, created an issue for everything where the grammar is not indent for now. Gonna keep on working on this.
Please check:
https://github.com/thorbenvh8/chevrotain-java/issues
any help would be appreciated

[jdubois]

We can definitely ask for help on Twitter, we have nearly 10K followers and this usually works well -> do you have a Twitter handle?

[deepu105]

PR merged for client side

[thorbenvh8]

my twitter handle is @thorbenvh8 and you can add @PrettierCode too if you'd like :)

[deepu105]

closing as the ticket scope is done, for the java part we can continue discussion here

[jdubois]

Awesome work @arthurescriou ! BTW I also wanted to thank you on Twitter but couldn't find your handle -> do you have one?

[atomfrede]

Spotless now has a maven plugin which works quite well (we have tried it at work already). So maybe spotless is worth a look again (until we can use prettier for everything).

Note: The setup we have tried uses the eclipse formatter (with plugin for IDEA) so configuration of import order etc. is quite easy.