search

HubSpot / prettier-maven-plugin

Apache License 2.0
116 stars 23 forks source link

Upgrade prettierJavaVersion default to 1.0.2 #44

Closed tomereli closed 3 years ago

tomereli commented 3 years ago

Hi! Thank you for the fast response! That helps a lot. Maybe it makes sense to add <prettierJavaVersion>1.0.2</prettierJavaVersion > to the "Example Usage" in the README.md.

Originally posted by @julius-d in https://github.com/HubSpot/prettier-maven-plugin/issues/41#issuecomment-808029208

jhaber commented 3 years ago

Yes great idea, sorry for the delay 06498dcc42203463985d1e158dfd701d23244488

tomereli commented 3 years ago

Thanks @jhaber - when is the next release planned? I guess this will be part of 0.14, right? Is there any plan of adding more prettier plugins? XML plugin will be especially useful IMO.

jhaber commented 3 years ago

The readme doesn't get bundled into the releases, so I don't think we need to make a new release for this change (the updated example just shows up here: https://github.com/HubSpot/prettier-maven-plugin#example-usage)

Adding support for extra prettier plugins is interesting. I'm imagining there could be some sort of <extraPrettierPlugins> parameter, but I'm not sure what it would accept. Maybe Maven coordinates? That would mean users are responsible for packaging any prettier plugins they want to use as Maven artifacts, which is a bit of a hassle. The most convenient thing would probably be to accept npm package names, and update this project to be able to install npm packages.

If we did that, then we could also install prettier + prettier-java directly from npm as well without needing to bundle them. The big benefit there is that we wouldn't need to push new releases of this plugin in order to use new versions of prettier-java

tomereli commented 3 years ago

The readme doesn't get bundled into the releases, so I don't think we need to make a new release for this change (the updated example just shows up here: https://github.com/HubSpot/prettier-maven-plugin#example-usage)

Adding support for extra prettier plugins is interesting. I'm imagining there could be some sort of <extraPrettierPlugins> parameter, but I'm not sure what it would accept. Maybe Maven coordinates? That would mean users are responsible for packaging any prettier plugins they want to use as Maven artifacts, which is a bit of a hassle. The most convenient thing would probably be to accept npm package names, and update this project to be able to install npm packages.

If we did that, then we could also install prettier + prettier-java directly from npm as well without needing to bundle them. The big benefit there is that we wouldn't need to push new releases of this plugin in order to use new versions of prettier-java

Yep, sounds like a nice addition, and will mean its a full-featured prettier maven plugin and not just a prettier+java maven plugin. We've decided not to use this plugin eventually for this reason for this reason, the other one being the fact that for some strange reason the formatting expected by this plugin for Java source files differs slightly from what the official prettier VSCode plugin (one of them expects new line after class declaration, the other disagrees). We ended up using https://github.com/eirslett/frontend-maven-plugin and use its npm install goal to install prettier with whatever extensions we want, then the npx goal for running prettier. Its a hack, and it means we need to locally install prettier with all its plugins as part of build, so if prettier-maven-plugin gets generalized and supported with VSCode we would love to switch.