@mshima/generator-jhipster-nodejs 0.0.0-stage → 0.0.2

package/generators/node-server/templates/Dockerfile.ejs

@@ -0,0 +1,54 @@
+<%_
+const serverDir = nodeServerRootDir.replace(/\/$/, '');
+const clientDir = clientRootDir.replace(/\/$/, '');
+_%>
+# Build stage: installs every dependency and builds the application.
+FROM node:<%- nodeVersion %>-alpine AS build
+
+WORKDIR /usr/src/app
+
+# The package-lock.json of the application, missing in a workspace of applications (its lock is the one of the workspace).
+COPY package*.json ./
+COPY <%- nodeServerRootDir %>package.json <%- nodeServerRootDir %>
+<%_ if (clientFrameworkAny) { _%>
+COPY <%- clientRootDir %>package.json <%- clientRootDir %>
+<%_ } _%>
+# The install scripts (native bindings of the development database, husky, Cypress) are not needed to build. npm install
+# installs the versions of the package-lock.json, or resolves them and writes one, the runtime stage installs from it.
+RUN npm install --ignore-scripts
+
+COPY . .
+RUN npm run build --workspace <%- serverDir %>
+<%_ if (clientFrameworkAny) { _%>
+# The client is built into <%- nodeServerRootDir %>dist/static, served by the server.
+RUN npm run build --workspace <%- clientDir %>
+<%_ } _%>
+
+# Runtime stage: the production dependencies of the server and its build only.
+FROM node:<%- nodeVersion %>-alpine
+
+WORKDIR /usr/src/app
+
+ENV NODE_ENV=production
+ENV BACKEND_ENV=prod
+ENV NODE_SERVER_PORT=<%- serverPort %>
+
+COPY package.json ./
+COPY --from=build /usr/src/app/package-lock.json ./
+COPY <%- nodeServerRootDir %>package.json <%- nodeServerRootDir %>
+<%_ if (clientFrameworkAny) { _%>
+COPY <%- clientRootDir %>package.json <%- clientRootDir %>
+<%_ } _%>
+RUN npm ci --omit=dev --ignore-scripts --workspace <%- serverDir %> && npm cache clean --force
+
+COPY --from=build /usr/src/app/<%- nodeServerRootDir %>dist <%- nodeServerRootDir %>dist
+
+USER node
+WORKDIR /usr/src/app/<%- serverDir %>
+
+EXPOSE <%- serverPort %>
+
+HEALTHCHECK --interval=10s --timeout=5s --start-period=30s --retries=5 \
+  CMD ["node", "-e", "fetch(`http://localhost:${process.env.NODE_SERVER_PORT}/management/health`).then(r => process.exit(r.ok ? 0 : 1), () => process.exit(1))"]
+
+CMD ["node", "dist/main.js"]

package/generators/node-server/templates/README.md.jhi.nodejs.ejs

@@ -0,0 +1,220 @@
+<%#
+ Copyright 2019-2023 the original author or authors from the JHipster project
+
+ This file is part of the JHipster project, see https://www.jhipster.tech/
+ for more information.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+      https://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-%>
+<%#
+ This is a fragment file, it will be merged into to root template if available.
+ EJS fragments will process % delimiter tags in template and & delimiter tags in the merge process.
+-%>
+<&_ if (fragment.introSection) { -&>
+This application was generated using the [NodeJS blueprint](https://github.com/jhipster/generator-jhipster-nodejs) of JHipster <%= jhipsterVersion %>, you can find documentation and help at [<%= documentationArchiveUrl %>](<%= documentationArchiveUrl %>). For any questions you can refer to the stream lead: [Angelo Manganiello](https://github.com/amanganiello90).
+<%_ if (applicationTypeGateway || applicationTypeMicroservice) { _%>
+
+This is a "<%= applicationType %>" application intended to be part of a microservice architecture, please refer to the [Doing microservices with JHipster][] page of the documentation for more information.
+<%_ if (serviceDiscoveryEureka) { _%>
+This application is configured for Service Discovery and Configuration with the JHipster-Registry, enabled with `EUREKA_CLIENT_ENABLED=true` (at `eureka.client.service-url.defaultZone`, [http://localhost:8761](http://localhost:8761) by default). Enabled, it refuses to start if it is not able to load its configuration from the JHipster-Registry, then registers once it listens and deregisters when it stops. For more information, read our documentation on [Service Discovery and Configuration with the JHipster-Registry][].
+<%_ } _%>
+<%_ if (serviceDiscoveryConsul) { _%>
+This application is configured for Service Discovery with Consul, enabled with `CLOUD_CONSUL_ENABLED=true` (at `CLOUD_CONSUL_HOST` and `CLOUD_CONSUL_PORT`, [http://localhost:8500](http://localhost:8500) by default). Enabled, it registers once it listens, with the health check of `/management/health`, and deregisters when it stops; a failed registration is logged. For more information, read our documentation on [Service Discovery and Configuration with Consul][].
+<%_ } _%>
+<%_ } _%>
+
+<&_ } -&>
+
+<&_ if (fragment.structureSection) { -&>
+Node is required for generation and recommended for development. `package.json` is always generated for a better development experience with prettier, commit hooks, scripts and so on.
+
+In the project root, JHipster generates configuration files for tools like git, prettier, husky, and others that are well known and you can find references in the web.
+
+- `.yo-rc.json` - Yeoman configuration file
+JHipster configuration is stored in this file at `generator-jhipster` key. You may find `generator-jhipster-*` for specific blueprints configuration.
+- `.yo-resolve` (optional) - Yeoman conflict resolver
+Allows to use a specific action when conflicts are found skipping prompts for files that matches a pattern. Each line should match `[pattern] [action]` with pattern been a [Minimatch](https://github.com/isaacs/minimatch#minimatch) pattern and action been one of skip (default if ommited) or force. Lines starting with `#` are considered comments and are ignored.
+- `.jhipster/*.json` - JHipster entity configuration files
+- `/<%- dockerServicesDir %>` - Docker configurations for the application and services that the application depends on
+- `/<%- clientRootDir %>` - Web application.
+- `/server/` - NodeJS server application.
+
+<&_ } -&>
+
+<&_ if (fragment.developmentSection) { -&>
+
+<%_ if (authenticationTypeOauth2) { _%>
+### OAuth 2.0 / OpenID Connect
+
+Congratulations! You've selected an excellent way to secure your NHipster application. If you're not sure what OAuth and OpenID Connect (OIDC) are, please see [What the Heck is OAuth?](https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth)
+
+To log in to your app, you'll need to have [Keycloak](https://keycloak.org) up and running. The JHipster Team has created a Docker container for you that has the default users and roles. Start Keycloak using the following command.
+
+```
+docker compose -f <%- dockerServicesDir %>keycloak.yml up
+```
+
+### Okta
+
+If you'd like to use Okta instead of Keycloak, it's pretty quick using the [Okta CLI](https://cli.okta.com/). After you've installed it, run:
+
+```shell
+okta register
+```
+
+Then, in your JHipster app's directory, run `okta apps create` and select **JHipster**. This will set up an Okta app for you, create `ROLE_ADMIN` and `ROLE_USER` groups, create a `.okta.env` file with your Okta settings, and configure a `groups` claim in your ID token.
+
+Run `source .okta.env` and start your app with `npm start`. You should be able to sign in with the credentials you registered with.
+
+If you're on Windows, you should install [WSL](https://docs.microsoft.com/en-us/windows/wsl/install-win10) so the `source` command will work.
+
+If you'd like to configure things manually through the Okta developer console, see the instructions below.
+
+First, you'll need to create a free developer account at <https://developer.okta.com/signup/>. After doing so, you'll get your own Okta domain, that has a name like `https://dev-123456.okta.com`.
+
+Modify `<%= nodeServerRootDir %>src/config/application.yml` to use your Okta settings.
+
+```yaml
+  ...
+  security:
+    oauth2:
+      client:
+        provider:
+          oidc:
+            issuer-uri: https://{yourOktaDomain}/oauth2/default
+        registration:
+          oidc:
+            client-id: {clientId}
+            client-secret: {clientSecret}
+```
+
+Create an OIDC App in Okta to get a `{clientId}` and `{clientSecret}`. To do this, log in to your Okta Developer account and navigate to **Applications** > **Add Application**. Click **Web** and click the **Next** button. Give the app a name you’ll remember, specify `http://localhost:<%- serverPort %>` as a Base URI, and `http://localhost:<%- serverPort %>/login/oauth2/code/oidc` as a Login Redirect URI. Click **Done**, then Edit and add `http://localhost:<%- serverPort %>` as a Logout redirect URI. Copy and paste the client ID and secret into your `application.yml` file.
+
+Create a `ROLE_ADMIN` and `ROLE_USER` group and add users into them. Modify e2e tests to use this account when running integration tests. You'll need to change credentials in `<%= clientTestDir %>e2e/account/account.spec.ts` and `<%= clientTestDir %>e2e/admin/administration.spec.ts`.
+
+Navigate to **API** > **Authorization Servers**, click the **Authorization Servers** tab and edit the default one. Click the **Claims** tab and **Add Claim**. Name it "groups", and include it in the ID Token. Set the value type to "Groups" and set the filter to be a Regex of `.*`.
+
+After making these changes, you should be good to go! If you have any issues, please post them to [Stack Overflow](https://stackoverflow.com/questions/tagged/jhipster). Make sure to tag your question with "jhipster" and "okta".
+
+<%_ } else if (authenticationTypeJwt) { _%>
+
+### JWT authentication and authorization
+
+Congratulations! You've selected an excellent way to secure your NHipster application. If you're not sure what JSON Web Token (JWT) is, please see [What the Heck is JWT?](https://jwt.io/introduction/)
+
+Your app uses, to get and use the token, the `<%= nodeServerRootDir %>src/config/application.yml` settings:
+
+```yaml
+  ...
+  security:
+    authentication:
+        jwt:
+            # This token must be encoded using Base64 and be at least 512 bits long, like the HS512 key of JHipster Spring Boot (you can type `openssl rand -base64 64` on your command line to generate one)
+            base64-secret: {yourSecret}
+            # Token is valid 24 hours
+            token-validity-in-seconds: 86400
+            token-validity-in-seconds-for-remember-me: 2592000
+```
+
+You can use the default secret created from the app, or change it.
+<%_ if (generateBuiltInUserEntity) { _%>
+So to get a token, you have to pass a POST request on the _api/authenticate_ url with **UserLoginDTO** as body.
+For this you can use the client login page (if you have generated it), or a client like curl.
+<%_ } else { _%>
+This application has no users of its own: it validates the tokens issued by the application sharing this secret (like the gateway), and the user of a request is the one of its token.
+<%_ } _%>
+<%_ } else if (authenticationTypeSession) { _%>
+
+### Session authentication
+
+Like JHipster Spring Boot with HTTP sessions, the client logs in by posting the `username`, `password` and `remember-me`
+form to `api/authentication`, and logs out by posting to `api/logout`. The sessions are kept in the database of the
+application (the `<%- jhiTablePrefix %>_session` table or collection): they outlive a restart and are shared by the instances of a
+cluster. A session ends after 30 minutes without requests, 31 days with remember-me, and the account page lists the
+sessions of the user, any of which it can end. Its unsafe requests, the login included, send the token of the
+`XSRF-TOKEN` cookie as the `X-XSRF-TOKEN` header, as the JHipster clients do. The secret of the sessions is
+`jhipster.security.session.secret`, set it in production with the `JHIPSTER_SECURITY_SESSION_SECRET` environment variable.
+<%_ } _%>
+<%_ if (generateUserManagement) { _%>
+
+### Account mails
+
+Like JHipster Spring Boot, the server sends the account mails with [@nestjs-modules/mailer][] (Nodemailer): the activation mail of a registered user (who signs in once activated, with the link of the mail), the creation mail of a user created by an administrator and the password reset mail. Their HTML is the [Handlebars][] templates of `<%= nodeServerRootDir %>src/templates/mail/` (like the Thymeleaf templates of `templates/mail`; they interpolate values, escaped, and call the `message` helper of the server, they run no code), their texts the messages of `<%= nodeServerRootDir %>src/i18n/messages*.properties` in the language of the user, and their links open the client at `jhipster.mail.base-url`.
+
+The SMTP server is set by the `mail` settings of `<%= nodeServerRootDir %>src/config/application-dev.yml` and `application-prod.yml` (`localhost:25` by default), or by environment variables like `MAIL_HOST`, `MAIL_PORT`, `MAIL_USERNAME` and `MAIL_PASSWORD`. A mail that cannot be sent is logged as a warning, without failing the request.
+<%_ } _%>
+
+### Using NestJS CLI
+
+You can also use [NestJS CLI][] to generate some custom server code.
+
+For example, the following command:
+
+    nest generate module my-module
+
+will generate the file:
+
+    create <%= nodeServerRootDir %>src/my-component/my-component.module.ts
+
+
+### Building and running
+
+#### Running
+
+```bash
+<%= nodePackageManager %> run app:start
+```
+
+#### Building
+
+```bash
+<%= nodePackageManager %> run build:app
+```
+
+The build folder with all compiled sources will be **<%= nodeServerRootDir %>dist**.
+
+> For more explanation about full stack server/client build refer to [<%= nodeServerRootDir %>README.md](<%= nodeServerRootDir %>README.md)
+
+<&_ } -&>
+
+<&_ if (fragment.othersSection) { -&>
+
+### Code quality using Sonar
+
+Sonar is used to analyse code quality. You can start a local Sonar server (accessible on http://localhost:9001) with:
+
+```
+docker compose -f <%- dockerServicesDir %>sonar.yml up -d
+```
+
+Note: we have turned off forced authentication redirect for UI in [<%- dockerServicesDir %>sonar.yml](<%- dockerServicesDir %>sonar.yml) for out of the box experience while trying out SonarQube, for real use cases turn it back on.
+
+You can run a Sonar analysis with using the [sonar-scanner](https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner).
+Then, run a Sonar analysis in the <%= nodeServerRootDir %> folder:
+
+```sh
+npm run sonar:scanner
+```
+
+For more information, refer to the [Code quality page][].
+
+<&_ } -&>
+
+<&_ if (fragment.referenceSection) { -&>
+[Node.js]: https://nodejs.org/
+[Vitest]: https://vitest.dev/
+[NestJS]: https://nestjs.com/
+[NestJS CLI]: https://docs.nestjs.com/cli/usages
+[@nestjs-modules/mailer]: https://nest-modules.github.io/mailer/
+[Handlebars]: https://handlebarsjs.com/
+<&_ } -&>

package/generators/node-server/templates/package.json.ejs

@@ -0,0 +1,82 @@
+<%#
+ Copyright 2019-2023 the original author or authors from the JHipster project.
+
+ This file is part of the JHipster project, see https://www.jhipster.tech/
+ for more information.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+      https://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-%>
+{
+  "name": "<%= dasherizedBaseName %>",
+  "version": "0.0.0",
+  "description": "Description for <%= baseName %>",
+  "private": true,
+  "license": "UNLICENSED",
+  "cacheDirectories": [
+    "node_modules"
+  ],
+  "devDependencies": {
+    "@eslint/js": "<%- nodeServerDependencies['@eslint/js'] %>",
+    "concurrently": "<%= nodeDependencies['concurrently'] %>",
+    "eslint": "<%- nodeServerDependencies['eslint'] %>",
+    "eslint-config-prettier": "<%- nodeServerDependencies['eslint-config-prettier'] %>",
+    "globals": "<%- nodeServerDependencies['globals'] %>",
+    "prettier": "<%= nodeDependencies['prettier'] %>",
+    "prettier-plugin-packagejson": "<%= nodeDependencies['prettier-plugin-packagejson'] %>",
+    "typescript-eslint": "<%- nodeServerDependencies['typescript-eslint'] %>"<% if (clientFrameworkAny) { %>,
+    "wait-on": "<%= nodeDependencies['wait-on'] %>"<% } %>
+  },
+  "engines": {
+    "node": ">=<%= nodeVersion %>"
+  },
+<%_ if (clientFrameworkAny) { _%>
+  "config": {
+    "backend_port": <%= serverPort %>
+  },
+<%_ } _%>
+  "workspaces": [
+      "server"
+  ],
+  "scripts": {
+    "backend:start": "<%= clientPackageManager %> run start:server",
+<%_ if (clientFrameworkAny) { _%>
+    "app:start": "<%= clientPackageManager %> run build && BACKEND_ENV=dev <%= clientPackageManager %> run start:prod -w server",
+    "ci:e2e:package": "<%= clientPackageManager %> run build",
+<%_ if ((testFrameworks ?? []).some(testFramework => ['cypress', 'playwright'].includes(testFramework))) { _%>
+    "e2e": "<%= clientPackageManager %> run e2e -w client",
+<%_ } _%>
+    "ci:e2e:server:start": "BACKEND_ENV=test <%= clientPackageManager %> run start:prod -w server",
+    "build": "<%= clientPackageManager %> run build -w server && <%= clientPackageManager %> run build -w client",
+<%_ } else { _%>
+    "build": "<%= clientPackageManager %> run build -w server",
+<%_ } _%>
+    "build:app": "<%= clientPackageManager %> run build -w server",
+    "ci:docker:build": "<%= clientPackageManager %> run docker:build",
+    "docker:build": "docker build -t <%= baseName.toLowerCase() %> .",
+    "lint": "<%= clientPackageManager %> run lint --workspaces",
+    "lint:fix": "<%= clientPackageManager %> run lint:fix --workspaces",
+<%_ if (clientFrameworkAny) { _%>
+    "start": "concurrently -k -s first -n application,client -c red,green npm:start:server npm:start:client",
+<%_ } else { _%>
+    "start": "<%= clientPackageManager %> run start:server",
+<%_ } _%>
+    "start:server": "<%= clientPackageManager %> run start -w server",
+<%_ if (clientFrameworkAny) { _%>
+    "start:client": "<%= clientPackageManager %> run start -w client",
+    "test:client": "<%= clientPackageManager %> test -w client",
+<%_ } _%>
+    "test:server": "<%= clientPackageManager %> test -w server",
+    "test:server:e2e": "<%= clientPackageManager %> run test:e2e -w server",
+    "test": "<%= clientPackageManager %> test --workspaces"
+  }
+}

package/generators/node-server/templates/server/README.md.ejs

@@ -0,0 +1,277 @@
+<p align="center">
+  <a href="http://nestjs.com/" target="blank"><img src="https://nestjs.com/img/logo_text.svg" width="320" alt="Nest Logo" /></a>
+</p>
+
+[travis-image]: https://api.travis-ci.org/nestjs/nest.svg?branch=master
+[travis-url]: https://travis-ci.org/nestjs/nest
+[linux-image]: https://img.shields.io/travis/nestjs/nest/master.svg?label=linux
+[linux-url]: https://travis-ci.org/nestjs/nest
+
+  <p align="center">A progressive <a href="http://nodejs.org" target="blank">Node.js</a> framework for building efficient and scalable server-side applications, heavily inspired by <a href="https://angular.io" target="blank">Angular</a>.</p>
+    <p align="center">
+        <a href="https://www.npmjs.com/~nestjscore"><img src="https://img.shields.io/npm/v/@nestjs/core.svg" alt="NPM Version" /></a>
+        <a href="https://www.npmjs.com/~nestjscore"><img src="https://img.shields.io/npm/l/@nestjs/core.svg" alt="Package License" /></a>
+        <a href="https://www.npmjs.com/~nestjscore"><img src="https://img.shields.io/npm/dm/@nestjs/core.svg" alt="NPM Downloads" /></a>
+        <a href="https://travis-ci.org/nestjs/nest"><img src="https://api.travis-ci.org/nestjs/nest.svg?branch=master" alt="Travis" /></a>
+        <a href="https://travis-ci.org/nestjs/nest"><img src="https://img.shields.io/travis/nestjs/nest/master.svg?label=linux" alt="Linux" /></a>
+        <a href="https://coveralls.io/github/nestjs/nest?branch=master"><img src="https://coveralls.io/repos/github/nestjs/nest/badge.svg?branch=master#5" alt="Coverage" /></a>
+        <a href="https://discord.gg/G7Qnnhy" target="_blank"><img src="https://img.shields.io/badge/discord-online-brightgreen.svg" alt="Discord"/></a>
+        <a href="https://opencollective.com/nest#backer"><img src="https://opencollective.com/nest/backers/badge.svg" alt="Backers on Open Collective" /></a>
+        <a href="https://opencollective.com/nest#sponsor"><img src="https://opencollective.com/nest/sponsors/badge.svg" alt="Sponsors on Open Collective" /></a>
+          <a href="https://paypal.me/kamilmysliwiec"><img src="https://img.shields.io/badge/Donate-PayPal-dc3d53.svg"/></a>
+          <a href="https://twitter.com/nestframework"><img src="https://img.shields.io/twitter/follow/nestframework.svg?style=social&label=Follow"></a>
+        </p>
+          <!--[![Backers on Open Collective](https://opencollective.com/nest/backers/badge.svg)](https://opencollective.com/nest#backer)
+          [![Sponsors on Open Collective](https://opencollective.com/nest/sponsors/badge.svg)](https://opencollective.com/nest#sponsor)-->
+
+## Description
+
+[NestJS Framework](https://github.com/nestjs/nest) server project generated from official [JHipster NodeJS blueprint](https://github.com/jhipster/generator-jhipster-nodejs).
+
+## Installation
+
+```bash
+$ npm install
+```
+
+## Project structure
+
+The server is organized by feature, like the modules NestJS generates (`nest g resource`): each feature folder of `src`
+has its module, its controllers, its services, its entities and its DTOs, the unit tests (`*.spec.ts`) next to the code
+they test, the end-to-end tests in `e2e`.
+
+- `src/entities/<entity>/`: an entity of the JDL, its TypeORM entity, its DTO (`dto/`), its mapper, its service, its
+  REST controller and its module; `src/entities/enumeration/` the enumerations of the entities.
+<%_ if (generateBuiltInUserEntity) { _%>
+- `src/users/`: the users and their authorities, their administration API.
+<%_ } _%>
+- `src/auth/`: the authentication, its guards, its decorators, its strategies and the account API.
+<%_ if (generateUserManagement) { _%>
+- `src/mail/`: the emails of the user management.
+<%_ } _%>
+- `src/management/`: the management endpoints (health, metrics, loggers, configuration, API documentation).
+<%_ if (serviceDiscoveryAny) { _%>
+- `src/registry/`: the registration of the service in its registry.
+<%_ } _%>
+- `src/common/`: the helpers of every feature: the errors, the HTTP helpers, the base entity and the column types
+  (`database/`), the base DTO.
+- `src/config/`: the configuration of each profile; `src/migrations/`: the migrations of the database schema.
+
+## TypeORM configuration
+
+### The database of each profile
+
+The database of each profile is the `database` section of its configuration file, read by
+[src/orm.config.ts](src/orm.config.ts) (the TypeORM options):
+
+- [src/config/application-dev.yml](src/config/application-dev.yml): the database of development, the one of the
+  `docker` folder<% if (databaseTypeSql) { %> (or a SQLite file)<% } %>;
+- [src/config/application-test.yml](src/config/application-test.yml): <%= databaseTypeSql ? 'an in-memory SQLite database' : 'an in-memory MongoDB server' %> for the tests;
+- [src/config/application-prod.yml](src/config/application-prod.yml): the production database, the service of the
+  docker compose files by default.
+
+```yaml
+database:
+  type: <%= nodeProdDatabaseType %>
+  host: localhost
+  port: 5432
+  username: YOUR_USER
+  password: 'YOUR_PASSWORD'
+  name: YOUR_DATABASE_NAME
+  logging: false
+```
+
+Like every property, an environment variable overrides them: `DATABASE_HOST`, `DATABASE_PORT`, `DATABASE_USERNAME`,
+`DATABASE_PASSWORD`, `DATABASE_NAME`. Keep the production password out of the file this way.
+
+### Configuration from environment variables
+
+Like in a Spring Boot application, an environment variable overrides a property of the `src/config/application*.yml`
+files: its name is the property in upper case, with the dots as underscores and the dashes removed (or as
+underscores). For example, `JHIPSTER_MAIL_BASEURL` sets `jhipster.mail.base-url`. Secrets, like the JWT secret, can
+be kept out of the configuration files this way in production.
+
+### Migration data and schema
+
+According [typeORM migration guide](https://github.com/typeorm/typeorm/blob/master/docs/migrations.md),
+there are under [src/migrations/](src/migrations/) the scripts to create the database schema and after to insert data seed.
+The application runs the ones not run yet at startup, in the order of the timestamp of their name.
+<%_ if (databaseTypeSql) { _%>
+
+Like the Liquibase changelogs of JHipster Spring Boot, JHipster generates the migrations of the schema: `CreateTables`
+creates the tables of the users and of the authorities, then each entity has the migration adding its table
+(`<timestamp>-AddedEntity<Entity>.ts`, the timestamp of its `changelogDate`) and, when it has relationships, the one adding
+its foreign keys and its join tables (`<timestamp>-AddedEntityConstraints<Entity>.ts`, its timestamp plus 3000000000000),
+run after the tables of every entity, like the constraints changelogs of Liquibase. A database the application ran them
+on already is not changed by a regeneration of a migration.
+
+Like the incremental changelogs of Liquibase, a regeneration keeps the migrations of an entity and generates the ones of
+its changes since, run after the others (their timestamp plus <%= nodejsMigrationTimestampOffset %>):
+`<timestamp>-UpdatedEntity<Entity>.ts` adds the columns of the added fields and drops the ones of the removed fields,
+then `<timestamp>-UpdatedEntityConstraints<Entity>.ts` adds and drops the join columns, their foreign keys and the join
+tables of the relationships, and `<timestamp>-RemovedEntity<Entity>.ts` drops the join tables and the table of a removed
+entity, after the updates of the entities whose relationships referenced it. The changes are the changelogs JHipster
+records in the `objects` of `.yo-rc.json`, one for each change of the database schema of an entity: keep them with the
+migrations, the migrations of the application are the ones of its changelogs. A field changed (its type, its
+validations) and a table renamed are not migrated, a dropped column or table keeps none of its values, and a required
+field added to a table having rows needs a migration of your own giving them a value
+(`npm run typeorm:migration:generate`).
+
+The application runs the migrations [src/orm.config.ts](src/orm.config.ts) lists: import the class of a migration of
+your own and add it to `migrations`, so the application runs it at startup, like the ones JHipster adds. The
+`typeorm:migration:run` script runs every migration of the `src/migrations` folder (built in `dist/migrations`).
+
+TypeORM runs the migrations in the order of the timestamp ending their class name. The `typeorm:migration:create` and
+`typeorm:migration:generate` scripts give a migration of your own its time plus <%= nodejsMigrationTimestampOffset %>
+(see [typeorm-migration.ts](typeorm-migration.ts)), so it runs after the migrations JHipster generates for the entities,
+on an empty database too, like the changelogs added at the end of the `master.xml` of Liquibase.
+<%_ } _%>
+
+The `typeorm` npm scripts build the server and run the typeorm CLI on the database `BACKEND_ENV` selects (see
+[ormconfig.ts](ormconfig.ts)):
+
+```bash
+<%_ if (databaseTypeSql) { _%>
+# generate a migration from the changes of the entities
+$ npm run typeorm:migration:generate
+<%_ } _%>
+# create an empty migration
+$ npm run typeorm:migration:create
+# run, revert or list the migrations
+$ npm run typeorm:migration:run
+$ npm run typeorm:migration:revert
+$ npm run typeorm:migration:show
+<%_ if (databaseTypeSql) { _%>
+# show the SQL that would synchronize the schema with the entities
+$ npm run typeorm:schema:log
+<%_ } _%>
+```
+<%_ if (databaseTypeMongodb) { _%>
+
+With MongoDB, they run on the MongoDB of the dev profile (`npm run docker:db:up`), the test profile using an in-memory server. MongoDB has no
+schema to compare, so migrations are written by hand with the MongoDB API (`queryRunner.query()` does not support
+MongoDB): use `queryRunner.dataSource.mongoManager`.
+<%_ } _%>
+
+## Running the app
+
+```bash
+# development
+$ npm run start
+
+# watch mode
+$ npm run start:dev
+
+# build transpiling files in javascript
+$ npm run build
+
+# run javascript build from the source project
+$ npm run start:prod
+
+# run javascript build with node
+$ node dist/main.js
+```
+
+### Development profile and .env file
+
+The development scripts (`npm start`, `npm run start:dev`, `npm run start:debug`) run with the **BACKEND_ENV** of the
+[.env.dev](.env.dev) file, **dev**: the dev database and settings, the sample secrets and the API documentation. The
+built application (`npm run start:prod`, `node dist/main.js`, the Docker image) does not read it, like a Spring Boot jar
+built with the prod profile: set **BACKEND_ENV** where it runs, like `prod`.
+
+An optional `.env` file, ignored by git, holds local settings, like secrets: the application loads it with
+[dotenv](https://www.npmjs.com/package/dotenv) when it exists. A variable set in the environment wins over both files.
+
+### Profiles
+
+Like `spring.profiles.active` in a Spring Boot application, **BACKEND_ENV** is a comma separated list of profiles, for
+example `prod,api-docs`. Each profile loads its `application-{profile}.yml` file of the [config folder](src/config), when
+there is one, in the order of the list (the last one wins), and the profiles of its group (`profiles.group` of
+[application.yml](src/config/application.yml)): `dev` activates `secret-samples` and `api-docs`, `test` activates
+`secret-samples`. The standard profiles are:
+
+- `dev`, `prod` and `test`: the database and the settings of each environment;
+- `api-docs`: the OpenAPI document of the API at `/v3/api-docs`, for the administrators like JHipster Spring Boot<%= skipClient ? '' : ', read by the API page of the client' %>;
+- `secret-samples`: samples of the secrets (<%= authenticationType === 'oauth2' ? 'the session secret and the OAuth2 client' : authenticationType === 'session' ? 'the session secret' : 'the JWT secret' %><%= databaseTypeSql ? ', the username and the password of the database' : '' %>) for development and CI, in
+  [application-secret-samples.yml](src/config/application-secret-samples.yml). In production, set them with environment
+  variables instead, like `<%= authenticationType === 'oauth2' ? 'JHIPSTER_SECURITY_OAUTH2_CLIENT_REGISTRATION_OIDC_CLIENTSECRET' : authenticationType === 'session' ? 'JHIPSTER_SECURITY_SESSION_SECRET' : 'JHIPSTER_SECURITY_AUTHENTICATION_JWT_BASE64SECRET' %>`;
+- `tls`: HTTPS, with your PKCS#12 keystore (`SERVER_SSL_KEY_STORE` and `SERVER_SSL_KEY_STORE_PASSWORD`);
+- `tls-samples`: with `tls`, the self-signed sample keystore of [src/config/tls](src/config/tls), for development only.
+
+> You can define your custom profiles, with an application-{profile}.yml file in your [config folder](src/config); an
+> environment of its own needs the `database` section of that environment.
+
+The `/management/info` endpoint gives the active profiles to the client, which shows its ribbon on the
+`info.display-ribbon-on-profiles` ones.
+
+**BACKEND_ENV** can also be set in the environment of the process.
+For example:
+
+```bash
+
+# development in prod environment, with the API documentation and the sample secrets
+# in linux
+$ BACKEND_ENV=prod,api-docs,secret-samples npm run start
+# in windows
+$ set BACKEND_ENV=prod,api-docs,secret-samples&& npm run start
+
+# run javascript build with node in prod environment
+# in linux
+$ BACKEND_ENV=prod node dist/main.js
+# in windows
+$ set BACKEND_ENV=prod&& node dist/main.js
+```
+
+## Lint
+
+```bash
+# run lint
+$ npm run lint
+
+# fix lint issues
+$ npm run lint:fix
+
+```
+
+## Debug
+
+```bash
+# run this and after you can execute debug task in VSCode
+$ npm run start:debug
+
+```
+
+## Test
+
+```bash
+# unit tests
+$ npm run test
+
+# lint
+$ npm run lint
+
+# fix lint issues
+$ npm run lint:fix
+
+# test coverage of unit tests
+$ npm run test:cov
+
+# e2e tests with full app coverage report
+$ npm run test:e2e
+
+```
+
+## Support
+
+Nest is an MIT-licensed open source project. It can grow thanks to the sponsors and support by the amazing backers. If you'd like to join them, please [read more here](https://docs.nestjs.com/support).
+
+## Stay in touch
+
+- Community - [jhipster homepage](https://www.jhipster.tech)
+- Stream Lead - [Angelo Manganiello](https://github.com/amanganiello90)
+- Website And Guide - [https://nestjs.com](https://nestjs.com/)
+- Twitter - [@nestframework](https://twitter.com/nestframework)
+
+## License
+
+Nest is [MIT licensed](LICENSE).