> Markdown version of [Configuration](https://vaadin.com/docs/next/hilla/reference/configuration). Section index: [llms.txt](https://vaadin.com/docs/next/hilla/llms.txt)

# Configuration

## <a id="java-compiler-options"></a>Configure the TypeScript Generator

To allow the [TypeScript generator](https://vaadin.com/docs/next/hilla/reference/typescript-generator.md) to use the correct parameter names when building TypeScript files, you need to configure the Java compiler not to omit them by using the `javac -parameters` option. For example, the following shows how to configure the Maven plugin to include this compiler option:

`pom.xml`

```xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.10.1</version>
            <configuration>
                <encoding>UTF-8</encoding>
                <!-- tag::snippet[] -->
                <parameters>true</parameters>
                <!-- end::snippet[] -->
            </configuration>
        </plugin>
    </plugins>
</build>
```

## <a id="multi-module-projects-or-external-dependency-services"></a>Multi-Module Projects or External Dependency Services

Hilla searches for browser-callable services among the Spring beans that are available in the application. Services therefore don’t have to be in the application’s own package: those in another module of your project, or in a dependency such as the [SSO Kit](https://vaadin.com/docs/next/tools/sso.md), are found as well, as long as Spring instantiates them as beans.

> **Note: Services & Spring Dependencies**
>
> If services outside the main application package aren’t picked up, make sure that Spring finds them: either component scanning reaches their packages, or a configuration class declares them as beans.

The discovery needs the Spring Boot application class on the module’s classpath. When that class is in another module, configure the discovery explicitly, as described in [Explicit Discovery of Browser-Callable Classes](#endpoint-discovery).

## <a id="endpoint-discovery"></a>Explicit Discovery of Browser-Callable Classes (since V25.2)

During code generation, Hilla discovers browser-callable classes — classes annotated with `@BrowserCallable` or `@Endpoint` — automatically. The discovery relies on detecting the Spring Boot application class on the module’s classpath. In some setups, such as multi-module projects where the application class resides in a different module, this auto-detection fails.

In these cases, you can configure the discovery explicitly with the `mainClass` and `sourceClasses` plugin parameters. They are available on the `prepare-frontend`, `build-frontend`, and `generate` goals of the Hilla Maven plugin:

- `mainClass`

  The fully qualified name of the Spring Boot application class to use for discovering browser-callable classes.

- `sourceClasses`

  A list of fully qualified names of Spring configuration classes that declare the browser-callable beans. The classes are passed to the Spring AOT processor as `--spring.main.sources`, and are used when no Spring Boot application class is found on the classpath.

For example, to set the application class explicitly:

```xml
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <mainClass>com.example.application.Application</mainClass>
    </configuration>
</plugin>
```

Alternatively, if there is no Spring Boot application class available, list the Spring configuration classes that declare the browser-callable beans:

```xml
<plugin>
    <groupId>com.vaadin.hilla</groupId>
    <artifactId>hilla-maven-plugin</artifactId>
    <version>${hilla.version}</version>
    <configuration>
        <sourceClasses>
            <sourceClass>com.example.application.ApplicationConfiguration</sourceClass>
            <sourceClass>com.example.module.ModuleConfiguration</sourceClass>
        </sourceClasses>
    </configuration>
</plugin>
```

> **Note:** When either `mainClass` or `sourceClasses` is set, Hilla discovers browser-callable classes with the Spring AOT-based finder, and skips the default lookup-based auto-detection.

## <a id="ts-compiler-options"></a>TypeScript Compiler Options

The TypeScript compiler requires a `tsconfig.json` file. If there is no `tsconfig.json` in the project root, the `vaadin-maven-plugin` generates one.

The default configuration looks similar to the following:

`tsconfig.json`

```json
{
  "compilerOptions": {
    "sourceMap": true,
    "inlineSources": true,
    "module": "esNext",
    "target": "es2017",
    "moduleResolution": "node",
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "experimentalDecorators": true,
    "baseUrl": "frontend",
    "paths": {
      "Frontend/*": [
        "*"
      ]
    }
  },
  "include": [
    "frontend/**/*.ts",
    "frontend/index.js",
    "types.d.ts"
  ],
  "exclude": []
}
```

## <a id="core-pro-vaadin-react-components"></a>Core & Pro Vaadin React Components

Vaadin React components include free core components and Pro (commercial) components. They’re shipped in separate npm packages: `@vaadin/react-components`, which contains only free components; and `@vaadin/react-components-pro`, which contains only commercial components. Vaadin adds both of these packages to `package.json` if the `com.vaadin:vaadin` artifact is used in the Java project configuration. By default, this is done in the Maven `pom.xml`.

pom.xml

```xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin</artifactId>
</dependency>
```

If the `com.vaadin:vaadin-core` dependency is used, only the free `@vaadin/react-components` package is added:

pom.xml

```xml
<dependency>
	<groupId>com.vaadin</groupId>
	<artifactId>vaadin-core</artifactId>
</dependency>
```