# jhipster-sample-app: JHipster 9.4.0 Application Development and Packaging

> This TypeScript sample application demonstrates a JHipster 9.4.0 stack with Spring Boot, Angular, Maven, npm, Vitest, Cypress, Gatling, Docker, and optional PWA support. It is useful as a generated application reference, but the package metadata marks the application itself as UNLICENSED despite the repository-level Apache-2.0 license.

**jhipster/jhipster-sample-app** — This is a sample application created with JHipster

- Repository: https://github.com/jhipster/jhipster-sample-app
- Stars: 1,469 · Forks: 967
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jhipster-jhipster-sample-app

## What jhipster-sample-app Represents

jhipster-sample-app is an application generated with JHipster 9.4.0. Its purpose is not presented as a narrowly packaged library. It is a working reference that contains the client, server, build files, entity configuration, tests, and container definitions produced for a JHipster application. The repository is aimed at developers who want to inspect JHipster conventions or work through a generated full-stack setup.

The primary language listed for the repository is TypeScript, but the project is not a TypeScript-only application. Its structure combines Angular code under `src/main/webapp`, Java source under `src/main`, Maven configuration in `pom.xml`, and npm configuration in `package.json`. The repository also includes Cypress tests, Scala Gatling simulations, Docker Compose files, and JHipster entity definitions. This makes it broader than a component library and more useful when viewed as a generated application baseline.

The README points new contributors to the archived JHipster 9.4.0 documentation. That version boundary matters because the sample was generated by a specific generator release rather than described as a version-neutral JHipster project. There are no GitHub releases in the repository, so users cannot rely on a release history here to trace changes to the sample.

## Generated Configuration and Source Layout

The repository uses `.yo-rc.json` as its Yeoman configuration file. JHipster settings are stored under the `generator-jhipster` key, while entries beginning with `generator-jhipster-` can hold blueprint configuration. Entity-level generator data is placed in `.jhipster/*.json`. This arrangement exposes the inputs that define the generated application instead of presenting only its final output.

The `.yo-resolve` file is optional. According to the README, each line maps a Minimatch pattern to either `skip`, which is the default action, or `force`. Comment lines begin with `#`. This mechanism is intended to control conflict handling during Yeoman operations for matching files. It is a generation-time concern rather than a runtime feature of the sample application.

The root also contains configuration for common development services, including Git, Prettier, ESLint, Husky, Maven wrappers, Angular configuration, TypeScript configuration, Vitest configuration, and Cypress configuration. Based on the repository layout, the project is suitable for inspecting how generator output integrates several tools rather than only how an Angular client is built.

## Backend, Client, and Browser Data Flow

The documented development model starts the Spring Boot backend and the Angular application as separate processes. `./npmw run backend:start` invokes Maven with Node installation and npm tasks skipped, while `./npmw run start` launches the client-side development script from the generated npm configuration. Running them in separate terminals allows the browser application to refresh when client files change while the backend remains available to the client.

The README states that npm and Angular CLI use esbuild as the build system. During a production Maven build, client CSS and JavaScript are concatenated and minified, and `index.html` is changed to reference the generated files. The resulting server artifact therefore contains a built client rather than relying on the development-only Angular workflow.

Optional PWA support is present but disabled. The service worker registration appears in `src/main/webapp/app/app.config.ts` with `enabled: false`. Enabling it requires changing that configuration so the Angular service worker can use `ngsw-worker.js`. The repository includes `ngsw-config.json`, but the README does not explain production caching policy or service worker deployment requirements, so those details would need confirmation in the archived JHipster documentation.

## Installing Dependencies and Starting Local Development

The documented build system installs the recommended Node and npm versions automatically. The `npmw` wrapper uses a locally installed npm rather than requiring the reader to rely on a globally selected version. Node is required for generation and recommended for development. Run the following command when dependencies from `package.json` need to be installed:

```bash
./npmw install
```

After installation, start the backend in one terminal:

```bash
./npmw run backend:start
```

Then start the frontend in a second terminal:

```bash
./npmw run start
```

The README does not give a separate development URL for the frontend, so it does not support inventing one. To inspect all available npm scripts, use:

```bash
./npmw run
```

This workflow assumes that the generated build tools can obtain their configured dependencies and that any configured external services are available. The repository includes Docker definitions for services the application depends on, but the README excerpt does not specify which services the default sample requires for the first local browser session.

## Testing Layers and Their Different Scopes

The generated project separates backend, client, browser, performance, and audit tests rather than treating `./mvnw verify` as the entire verification surface. Spring Boot tests are launched with `./mvnw verify`. Client unit tests use Vitest and live near components, so `./npmw test` is the documented entry point for that layer.

Gatling simulations are Scala files under `src/test/java/gatling/simulations`. The complete Gatling command is:

```bash
./mvnw gatling:test
```

Cypress covers UI end-to-end behavior from `src/test/javascript/cypress`. Its documented two-process setup differs slightly from the main development commands. First start Spring Boot with `./npmw run app:start`, then run `./npmw run e2e` in another terminal. Non-default credentials can be supplied through `CYPRESS_E2E_USERNAME` and `CYPRESS_E2E_PASSWORD`:

```bash
export CYPRESS_E2E_USERNAME="<your-username>"
export CYPRESS_E2E_PASSWORD="<your-password>"
```

These layers have different costs and diagnostic value. Maven tests exercise server-side behavior, Vitest covers client units, Cypress drives browser flows, and Gatling targets load scenarios. The README also starts a Lighthouse section, but the visible text ends before giving its command, so no Lighthouse invocation can be confirmed here.

## Production JAR, WAR, and Docker Choices

For a production executable JAR, the README gives this build command:

```bash
./mvnw -Pprod clean verify
```

The build performs client asset optimization. Start the generated artifact with:

```bash
java -jar target/*.jar
```

After it starts, open `http://localhost:8080`. That URL is the only application address confirmed by the README.

A WAR is available when deployment requires a Java application server rather than the executable JAR format:

```bash
./mvnw -Pprod,war clean verify
```

This is a packaging decision rather than a claim that either format is universally better. The README does not document rollback, migration sequencing, or the server version expected for WAR deployment. It also does not provide production database or service configuration in the visible text.

A separate optional local service is JHipster Control Center. Its documented command is:

```bash
docker compose -f src/main/docker/jhipster-control-center.yml up
```

The README states that this makes the control center accessible at `http://localhost:7419`. This service should not be confused with the sample application itself, which runs on port 8080 after the JAR is started.

## License, Maintenance, and Upgrade Boundaries

The repository is described as licensed under Apache-2.0, and the repository includes `LICENSE.txt`. However, `package.json` declares `"license": "UNLICENSED"` for the private application package. That discrepancy needs clarification before code, configuration, or generated artifacts from the sample are copied into a redistributed product. This is a metadata observation, not legal advice.

The repository is not archived, and its last push was on 2026-09-18. Its recent push date indicates current repository activity, but it does not establish that the generated application is compatible with every newer JHipster, Angular, Spring Boot, Node, or npm release. The project itself has no GitHub releases, and the README links to archived documentation for JHipster 9.4.0.

Dependency upgrades are exposed through `package.json`, while the README also documents `./npmw update` followed by `./npmw install`. For a version-sensitive adoption, the generated manifest, lock file status, Maven configuration, and archived 9.4.0 documentation should be reviewed together. The README does not document a formal upgrade procedure from JHipster 9.4.0 to a later generator version.

## Conclusion

Developers evaluating this repository can adopt it as a concrete JHipster 9.4.0 reference when they need to inspect or exercise its generated development, testing, and packaging setup. Teams wanting a reusable, permissively licensed application foundation should first resolve the mismatch between the repository-level Apache-2.0 designation and the UNLICENSED package.json entry. Verify the archived JHipster 9.4.0 documentation, generated entity configuration, service dependencies, and target deployment format before standardizing on the sample.

## FAQ

### How do I install dependencies and start jhipster-sample-app for development?

Run `./npmw install`, then launch `./npmw run backend:start` and `./npmw run start` in separate terminals. The wrapper handles the locally installed npm toolchain, and the two processes support backend and Angular development.

### How do I build jhipster-sample-app as a production JAR?

Run `./mvnw -Pprod clean verify`, then start the result with `java -jar target/*.jar`. The documented application URL is `http://localhost:8080`.

### How do I run the tests in jhipster-sample-app?

Use `./mvnw verify` for Spring Boot tests, `./npmw test` for Vitest client tests, and `./mvnw gatling:test` for Gatling simulations. Cypress end-to-end tests require Spring Boot in one terminal and `./npmw run e2e` in another.

### Is PWA support enabled in jhipster-sample-app?

No. Service worker registration is disabled by default in `src/main/webapp/app/app.config.ts` and must be enabled there.

## Sources

- [Issues](https://github.com/jhipster/jhipster-sample-app/issues)
- [jhipster/jhipster-sample-app on GitHub](https://github.com/jhipster/jhipster-sample-app)
- [License: Apache-2.0](https://github.com/jhipster/jhipster-sample-app/blob/main/LICENSE)
- [README](https://github.com/jhipster/jhipster-sample-app/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jhipster-jhipster-sample-app