Interface TypeScriptProjectOptions

Allow the project to include peerDependencies and bundledDependencies. This is normally only allowed for libraries. For apps, there's no meaning for specifying these.

A directory which will contain build artifacts.

Run security audit on dependencies. When enabled, creates an "audit" task that checks for known security vulnerabilities in dependencies. By default, runs during every build and checks for "high" severity vulnerabilities or above in all dependencies (including dev dependencies).

Security audit options.

Author's e-mail.

Author's name.

Is the author an organization.

Author's URL / Website.

Enable and configure the 'auto approve' workflow.

Automatically approve deps upgrade PRs, allowing them to be merged by mergify (if configured). Throw if set to true but autoApproveOptions are not defined.

Automatically add all executables under the bin directory to your package.json file under the bin section.

Enable automatic merging on GitHub. Has no effect if github.mergify is set to false.

Configure options for automatic merging on GitHub. Has no effect if github.mergify or autoMerge is set to false.

Binary programs vended with your module. You can use this option to add/customize how binaries are represented in your package.json, but unless autoDetectBin is false, every executable file under bin will automatically be added to this section.

Setup Biome.

Biome options.

The email address to which issues should be reported.

The url to your project's issue tracker.

Define a GitHub workflow for building PRs.

Options for PR build workflow.

The commit-and-tag-version compatible package used to bump the package version, as a dependency string. This can be any compatible package version, including the deprecated standard-version@9.

List of dependencies to bundle into this module. These modules will be added both to the dependencies section and bundledDependencies section of your package.json.

The recommendation is to only specify the module name here (e.g. express). This will behave similar to yarn add or npm install in the sense that it will add the module as a dependency to your package.json file with the latest version (^). You can specify semver requirements in the same syntax passed to npm i or yarn add (e.g. express@^2) and this will be what you package.json will eventually include.

Options for Bundler.

The version of Bun to use if using Bun as a package manager.

Configure which licenses should be deemed acceptable for use by dependencies. This setting will cause the build to fail, if any prohibited or not allowed licenses ares encountered.

Add a clobber task which resets the repo to origin.

Options for npm packages using AWS CodeArtifact. This is required if publishing packages to, or installing scoped packages from AWS CodeArtifact

Define a GitHub workflow step for sending code coverage metrics to https://codecov.io/ Uses codecov/codecov-action@v5 By default, OIDC auth is used. Alternatively a token can be provided via codeCovTokenSecret.

Define the secret name for a specified https://codecov.io/ token.

Whether to commit the managed files by default.

License copyright owner.

The copyright years to put in the LICENSE file.

The name of the main release branch.

Use dependabot to handle dependency upgrades. Cannot be used in conjunction with depsUpgrade.

Options for dependabot.

Runtime dependencies of this module. The recommendation is to only specify the module name here (e.g. express). This will behave similar to yarn add or npm install in the sense that it will add the module as a dependency to your package.json file with the latest version (^). You can specify semver requirements in the same syntax passed to npm i or yarn add (e.g. express@^2) and this will be what you package.json will eventually include.

Use tasks and github workflows to handle dependency upgrades. Cannot be used in conjunction with dependabot.

Options for UpgradeDependencies.

The description is just a string that helps people understand the purpose of the package. It can be used when searching for packages in a package manager as well. See https://classic.yarnpkg.com/en/docs/package-json/#toc-description

Add a VSCode development environment (used for GitHub Codespaces).

Build dependencies for this module. These dependencies will only be available in your build environment but will not be fetched when this module is consumed.

The recommendation is to only specify the module name here (e.g. express). This will behave similar to yarn add or npm install in the sense that it will add the module as a dependency to your package.json file with the latest version (^). You can specify semver requirements in the same syntax passed to npm i or yarn add (e.g. express@^2) and this will be what you package.json will eventually include.

Do not generate a tsconfig.json file (used by jsii projects since tsconfig.json is generated by the jsii compiler).

Do not generate a tsconfig.dev.json file.

Docgen by Typedoc.

Docs directory.

Module entrypoint (main in package.json). Set to an empty string to not include main in your package.json

The .d.ts file that includes the type declarations for this module.

Setup eslint.

Eslint options.

Enable GitHub integration. Enabled by default for root projects. Disabled for non-root projects.

Options for GitHub integration.

Additional entries to .gitignore.

Configuration options for .gitignore file.

Configuration options for git.

Add a Gitpod development environment.

Package's Homepage / Website.

Setup jest unit tests.

Jest options.

Version requirement of publib which is used to publish modules to npm.

Keywords to include in package.json.

Typescript artifacts output directory.

License's SPDX identifier. See https://github.com/projen/projen/tree/main/license-text for a list of supported licenses. Use the licensed option if you want to no license to be specified.

Indicates if a license should be added.

Configure logging options such as verbosity.

Major version to release from the default branch. If this is specified, we bump the latest version of this major version line. If not specified, we bump the global latest version.

The maximum node version supported by this package. Most projects should not use this option. The value indicates that the package is incompatible with any newer versions of node. This requirement is enforced via the engines field.

You will normally not need to set this option. Consider this option only if your package is known to not function with newer versions of node.

Minimal Major version to release. This can be useful to set to 1, as breaking changes before the 1.x major release are not incrementing the major version number.

Can not be set together with majorVersion.

The minimum node version required by this package to function. Most projects should not use this option. The value indicates that the package is incompatible with any older versions of node. This requirement is enforced via the engines field.

You will normally not need to set this option, even if your package is incompatible with EOL versions of node. Consider this option only if your package depends on a specific feature, that is not available in other LTS versions. Setting this option has very high impact on the consumers of your package, as package managers will actively prevent usage with node versions you have marked as incompatible.

To change the node version of your CI/CD workflows, use workflowNodeVersion.

This is the name of your project.

A shell command to control the next version to release. If present, this shell command will be run before the bump is executed, and it determines what version to release. It will be executed in the following environment:

• Working directory: the project directory.
• $VERSION: the current version. Looks like 1.2.3.
• $LATEST_TAG: the most recent tag. Looks like prefix-v1.2.3, or may be unset.
• $SUGGESTED_BUMP: the suggested bump action based on commits. One of major|minor|patch|none.

The command should print one of the following to stdout:

• Nothing: the next version number will be determined based on commit history.
• x.y.z: the next version number will be x.y.z.
• major|minor|patch: the next version number will be the current version number with the indicated component bumped.

This setting cannot be specified together with minMajorVersion; the invoked script can be used to achieve the effects of minMajorVersion.

Access level of the npm package.

The npmDistTag to use when publishing from the default branch. To set the npm dist-tag for release branches, set the npmDistTag property for each branch.

Defines an .npmignore file. Normally this is only needed for libraries that are packaged as tarballs.

Configuration options for .npmignore file.

Should provenance statements be generated when the package is published. A supported package manager is required to publish a package with npm provenance statements and you will need to use a supported CI/CD provider.

Note that the projen Release and Publisher components are using publib to publish packages, which is using npm internally and supports provenance statements independently of the package manager used.

The base URL of the npm package registry. Must be a URL (e.g. start with "https://" or "http://")

GitHub secret which contains the NPM token to use when publishing packages.

Use trusted publishing for publishing to npmjs.com Needs to be pre-configured on npm.js to work.

The root directory of the project. Relative to this directory, all files are synthesized.

If this project has a parent, this directory is relative to the parent directory and it cannot be the same as the parent or any of it's other subprojects.

Defines a package task that will produce an npm tarball under the artifacts directory (e.g. dist).

The Node Package Manager used to execute scripts.

The "name" in package.json.

The parent project, if this project is part of a bigger project.

Options for peerDeps.

Peer dependencies for this module. Dependencies listed here are required to be installed (and satisfied) by the consumer of this library. Using peer dependencies allows you to ensure that only a single module of a certain library exists in the node_modules tree of your consumers.

Note that prior to npm@7, peer dependencies are not automatically installed, which means that adding peer dependencies to a library will be a breaking change for your customers.

Unless peerDependencyOptions.pinnedDevDependency is disabled (it is enabled by default), projen will automatically add a dev dependency with a pinned version for each peer dependency. This will ensure that you build & test your module against the lowest peer version required.

The version of PNPM to use if using PNPM as a package manager.

Steps to execute after build as part of the release workflow.

Bump versions from the default branch as pre-releases (e.g. "beta", "alpha", "pre").

Setup prettier.

Prettier options.

Generate a project tree file (.projen/tree.json) that shows all components and their relationships. Useful for understanding your project structure and debugging.

The shell command to use in order to run the projen CLI. Can be used to customize in special environments.

Choose a method of providing GitHub API access for projen workflows.

Indicates of "projen" should be installed as a devDependency.

Generate (once) .projenrc.js (in JavaScript). Set to false in order to disable .projenrc.js generation.

Generate (once) .projenrc.json (in JSON). Set to false in order to disable .projenrc.json generation.

Options for .projenrc.json.

Options for .projenrc.js.

Use TypeScript for your projenrc file (.projenrc.ts).

Options for .projenrc.ts.

Version of projen to install.

Instead of actually publishing to package managers, just print the publishing command.

Define publishing tasks that can be executed manually as well as workflows. Normally, publishing only happens within automated workflows. Enable this in order to create a publishing task for each publishing activity.

Include a GitHub pull request template.

The contents of the pull request template.

The README setup.

Find commits that should be considered releasable Used to decide if a release is required.

Add release management to this project.

Defines additional release branches. A workflow will be created for each release branch which will publish releases from commits in this branch. Each release branch must be assigned a major version number which is used to enforce that versions published from that branch always use that major version. If multiple branches are used, the majorVersion field must also be provided for the default branch.

The GitHub Actions environment used for the release. This can be used to add an explicit approval step to the release or limit who can initiate a release through environment protection rules.

When multiple artifacts are released, the environment can be overwritten on a per artifact basis.

Create a github issue on every failed publishing task.

The label to apply to issues indicating publish failures. Only applies if releaseFailureIssue is true.

Automatically add the given prefix to release tags. Useful if you are releasing on multiple branches with overlapping version numbers. Note: this prefix is used to detect the latest tagged version when bumping, so if you change this on a project with an existing version history, you may need to manually tag your latest release with the new prefix.

Automatically release to npm when new versions are introduced.

The release trigger to use.

Build environment variables for release workflows.

The name of the default release workflow.

A set of workflow steps to execute in order to setup the workflow container.

Use renovatebot to handle dependency upgrades.

Options for renovatebot.

The repository is the location where the actual code for your package lives. See https://classic.yarnpkg.com/en/docs/package-json/#toc-repository

If the package.json for your package is not in the root directory (for example if it is part of a monorepo), you can specify the directory in which it lives.

Generate one-time sample in src/ and test/ if there are no files there.

Options for privately hosted scoped packages.

Typescript sources directory.

Package's Stability.

Auto-close of stale issues and pull request. See staleOptions for options.

Auto-close stale issues and pull requests. To disable set stale to false.

Jest tests directory. Tests files should be named xxx.test.ts. If this directory is under srcdir (e.g. src/test, src/__tests__), then tests are going to be compiled into lib/ and executed as javascript. If the test directory is outside of src, then we configure jest to compile the code in-memory.

Custom TSConfig.

TypescriptConfigExtends to use as base.

Custom tsconfig options for the development tsconfig.json file (used for testing).

The name of the development tsconfig.json file.

Options for ts-jest.

TypeScript version to use. NOTE: Typescript is not semantically versioned and should remain on the same minor, so we recommend using a ~ dependency (e.g. ~1.2.3).

Use unbuild for bundling/transpiling.

Custom configuration used when creating changelog with commit-and-tag-version package. Given values either append to default configuration or overwrite values in it.

Enable VSCode integration. Enabled by default for root projects. Disabled for non-root projects.

Workflow steps to use in order to bootstrap this repo.

Container image to use for GitHub workflows.

The git identity to use in workflows.

The node version used in GitHub Actions workflows. Always use this option if your GitHub Actions workflows require a specific to run.

Enable Node.js package cache in GitHub workflows.

Github Runner selection labels.

Github Runner Group selection options.

Dependencies linked by the workspace protocol.

Options for Yarn Berry.