Merge pull request #6810 from murdos/prettier3

Upgrade to prettier 3

.github/dependabot.yml

@@ -67,8 +67,8 @@ updates:
     labels:
       - 'area: dependencies'
     ignore:
-      - dependency-name: "node"
-        versions: ["15.x", "17.x", "19.x", "20.x"]
+      - dependency-name: 'node'
+        versions: ['15.x', '17.x', '19.x', '20.x']
   - package-ecosystem: 'npm'
     directory: '/src/main/resources/generator/dependencies/vue'
     schedule:

.github/workflows/docker-image-publish.yml

@@ -3,8 +3,8 @@ on:
   workflow_dispatch:
   push:
     # Avoid building on main branch - see https://github.com/jhipster/jhipster-lite/issues/5341
-#    branches:
-#      - main
+    #    branches:
+    #      - main
     # Publish semver tags as releases.
     tags:
       - 'v*.*.*'

.github/workflows/triage.yml

@@ -11,5 +11,5 @@ jobs:
       - name: initial labeling
         uses: andymckay/labeler@master
         with:
-          add-labels: "area: triage"
+          add-labels: 'area: triage'
           ignore-if-labeled: true

.lintstagedrc.js

@@ -2,7 +2,6 @@ module.exports = {
   '{src/test/javascript,src/main/webapp}/**/*.{js,ts,tsx,vue}': ['eslint --fix'],
   'src/main/style/**/*.{css,scss}': ['stylelint --fix'],
   'src/main/style/**/*.pug': ['pug-lint'],
-  '{{src/**/,}*.{md,json,yml,html,vue,java,xml},*.{js,ts},src/{main/webapp,main/glyph,test/javascript}/**/*.{css,scss}}': [
-    'prettier --write',
-  ],
+  '{{src/**/,}*.{md,json,yml,html,vue,java,xml},*.{js,ts},.github/**/*.yml,documentation/**/*.md,src/{main/webapp,main/glyph,test/javascript}/**/*.{css,scss}}':
+    ['prettier --write'],
 };

.prettierrc

@@ -5,6 +5,10 @@ singleQuote: true
 tabWidth: 2
 useTabs: false
 
+plugins:
+  - '@prettier/plugin-xml'
+  - prettier-plugin-java
+
 # js and ts rules:
 arrowParens: avoid
 

documentation/module-creation.md

@@ -1,19 +1,19 @@
 # Creating a JHLite module
 
-So you want to create a JHLite module? Great!  
+So you want to create a JHLite module? Great!
 
 For that you'll need to provide 2 main parts:
 
-* `JHipsterModuleResource`: describe the module organization, it is used to generate the APIs;
-* `JHipsterModule`: describe the changes done by the module.
+- `JHipsterModuleResource`: describe the module organization, it is used to generate the APIs;
+- `JHipsterModule`: describe the changes done by the module.
 
 You can start by the element you prefer but to create a `JHipsterModuleResource` you'll need to be able to build a `JHipsterModule`.
 
 ## Creating a JHipsterModule
 
 In fact, you don't just need to create one `JHipsterModule`, you'll need a factory able to create them since each instance depends on the properties chosen by the users.
 
-So, as this is the business of JHLite you probably want to create a `tech.jhipster.lite.generator.my_module.domain` package. And you can start with a simple test: 
+So, as this is the business of JHLite you probably want to create a `tech.jhipster.lite.generator.my_module.domain` package. And you can start with a simple test:
 
 ```java
 import static tech.jhipster.lite.module.infrastructure.secondary.JHipsterModulesAssertions.*;
@@ -27,6 +27,7 @@ import tech.jhipster.lite.module.domain.properties.JHipsterModuleProperties;
 
 @UnitTest
 class MyModuleFactoryTest {
+
   private static final MyModuleFactory factory = new MyModuleFactory();
 
   @Test
@@ -38,19 +39,19 @@ class MyModuleFactoryTest {
 
     JHipsterModule module = factory.buildModule(properties);
 
-    assertThatModule(module)
-      .hasPrefixedFiles("src/main/java/com/jhipster/test/my_package", "Dummy.java");
+    assertThatModule(module).hasPrefixedFiles("src/main/java/com/jhipster/test/my_package", "Dummy.java");
   }
 }
+
 ```
 
-A few things to note here: 
+A few things to note here:
 
-* We are expecting to have a `buildModule(...)` method in `MyModuleFactory`;
-* The `JHipsterModulesAssertions.assertThatModule(...)` will really apply the module to a project and give you a fluent API to ensure some operations;
-* Even if the feedback loops are not perfect on that they should be short enough to allow a decent TDD implementation of the factory (on eclipse with [infinitest](https://infinitest.github.io/) feedbacks are under a second).
+- We are expecting to have a `buildModule(...)` method in `MyModuleFactory`;
+- The `JHipsterModulesAssertions.assertThatModule(...)` will really apply the module to a project and give you a fluent API to ensure some operations;
+- Even if the feedback loops are not perfect on that they should be short enough to allow a decent TDD implementation of the factory (on eclipse with [infinitest](https://infinitest.github.io/) feedbacks are under a second).
 
-So, now that we have a first test we can do a simple implementation: 
+So, now that we have a first test we can do a simple implementation:
 
 ```java
 import static tech.jhipster.lite.module.domain.JHipsterModule.*;
@@ -69,11 +70,12 @@ public class MyModuleFactory {
     //@formatter:on
   }
 }
+
 ```
 
 This implementation will take a file from `src/main/resources/generator/my-module` and put it in the generated project.
 
-The file is a template named `Dummy.java.mustache` and can contains some mustache placeholders: 
+The file is a template named `Dummy.java.mustache` and can contains some mustache placeholders:
 
 ```java
 package {{packageName}}.my_package;
@@ -92,24 +94,26 @@ And this is it for this part of the documentation... Of course you can do a lot
 
 ### Dependency resolution
 
-* In the `src/main/resources/generator/dependencies` folder, different files are maintained to handle the dependencies for different tools/frameworks such as docker, maven, angular etc.
-* You can add the dependencies required for your new module in the respective files in the `dependencies` folder.
-* The dependency versions are then automatically managed by the dependabot.
+- In the `src/main/resources/generator/dependencies` folder, different files are maintained to handle the dependencies for different tools/frameworks such as docker, maven, angular etc.
+- You can add the dependencies required for your new module in the respective files in the `dependencies` folder.
+- The dependency versions are then automatically managed by the dependabot.
 
 ### Overview of Version files/folders in this dependencies folder
 
-* **Docker versions**
-  * You can add the docker images required for your module in the `src/main/resources/generator/dependencies/Dockerfile`
-  * These dependencies are resolved using the [FileSystemDockerImagesReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/docker/FileSystemDockerImagesReader.java), an implementation of the `DockerImagesReader` bean to read from a local file.
+- **Docker versions**
 
-* **Java versions**
-  * You can add the java dependencies required for your module in the `src/main/resources/generator/dependencies/pom.xml`
-  * These dependencies are resolved using [FileSystemJavaDependenciesReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/javadependency/FileSystemJavaDependenciesReader.java), an implementation of the `JavaDependenciesReader` bean to read from a local file.
+  - You can add the docker images required for your module in the `src/main/resources/generator/dependencies/Dockerfile`
+  - These dependencies are resolved using the [FileSystemDockerImagesReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/docker/FileSystemDockerImagesReader.java), an implementation of the `DockerImagesReader` bean to read from a local file.
 
-* **NPM versions**
-  * Common npm dependencies can be added in the `src/main/resources/generator/dependencies/common/package.json`
-  * Framework specific npm dependencies can be added in the `package.json` of the respective framework folders. For eg: `src/main/resources/generator/dependencies/react/package.json`
-  * These dependencies are resolved using [FileSystemNpmVersionReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/npm/FileSystemNpmVersionReader.java), an implementation of the `NpmVersionsReader` bean to read from a local file.
+- **Java versions**
+
+  - You can add the java dependencies required for your module in the `src/main/resources/generator/dependencies/pom.xml`
+  - These dependencies are resolved using [FileSystemJavaDependenciesReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/javadependency/FileSystemJavaDependenciesReader.java), an implementation of the `JavaDependenciesReader` bean to read from a local file.
+
+- **NPM versions**
+  - Common npm dependencies can be added in the `src/main/resources/generator/dependencies/common/package.json`
+  - Framework specific npm dependencies can be added in the `package.json` of the respective framework folders. For eg: `src/main/resources/generator/dependencies/react/package.json`
+  - These dependencies are resolved using [FileSystemNpmVersionReader](https://github.com/jhipster/jhipster-lite/blob/main/src/main/java/tech/jhipster/lite/module/infrastructure/secondary/npm/FileSystemNpmVersionReader.java), an implementation of the `NpmVersionsReader` bean to read from a local file.
 
 ## Creating JHipsterModuleResource
 
@@ -138,9 +142,7 @@ To be used by JHLite, the `JHipsterModuleResource` needs to be a Spring bean so,
 class MyModuleModuleConfiguration {
 
   @Bean
-  JHipsterModuleResource myModule(
-    MyModuleApplicationService myModules
-  ) {
+  JHipsterModuleResource myModule(MyModuleApplicationService myModules) {
     return JHipsterModuleResource
       .builder()
       .slug(JHLiteModuleSlug.MY_MODULE)
@@ -151,9 +153,10 @@ class MyModuleModuleConfiguration {
       .factory(myModules::buildModule);
   }
 }
+
 ```
 
-In fact, you don't really have choices here, the `JHipsterModuleResource.builder()` is fluent and will only let you go to the next possible step. 
+In fact, you don't really have choices here, the `JHipsterModuleResource.builder()` is fluent and will only let you go to the next possible step.
 The most confusing one may be the last one `.factory(myModules::buildModule)` which is, in fact, a method called to build the module.
 
 For this to work, we'll need to add a simple orchestration class in `tech.jhipster.lite.generator.my_module.application`: