projen 0.76.5 → 0.76.7

package/docs/awscdk-apps.md

@@ -1,18 +0,0 @@
-# AWS CDK Applications
-
-Project types: `awscdk-app-java`, `awscdk-app-py`, `awscdk-app-ts`.
-
-## Deployment (NOT IMPLEMENTED YET)
-
-CDK application projects produce complete cloud applications. When a commit is
-merged into the default branch, the app is rolled out by the release workflow to
-AWS environments.
-
-Possible implementation:
- - [Deployable Typescript AWS CDK App](https://github.com/AminFazlMondo/deployable-awscdk-app-ts)
-
-## Dev Stage (NOT IMPLEMENTED YET)
-
-Every app includes an instance of the application stage which can be deployed to
-a development AWS account. This allows each developer to use their AWS account
-as part of their development environment.

package/docs/awscdk-construct.md

@@ -1,195 +0,0 @@
-# AWS CDK Construct Library
-
-AWS CDK library projects produce artifacts with reusable constructs which can be
-consumed by other AWS CDK libraries or apps. Library artifacts are published to
-private or public package managers under a semantic version.
-
-By default, for every commit to the default branch, a new version is released
-(trunk-based development). This includes the following steps:
-
-1. Compile, lint and test the code.
-1. Use [JSII](https://github.com/aws/jsii) to produce library artifacts for all
-   target languages.
-1. Determine the next minor/patch version based on [conventional
-   commits](https://www.conventionalcommits.org). Major versions must be
-   explicitly bumped to protect consumers against breaking changes.
-1. A changelog entry is generated based on commit history.
-1. Packages are published to all target package managers.
-
-## Getting Started
-
-Start like all projen projects:
-
-```sh
-npx projen new awscdk-construct
-```
-
-Review the resulting .projenrc.js file and make changes as needed. The following are some specific areas
-you may want to set explicitly.
-
-## Module Metadata
-
-These fields are your basic Node module setup:
-
-```typescript
-authorAddress: 'benisrae@amazon.com',
-authorName: 'Elad Ben-Israel',
-description: 'Watching your CDK apps since 2019',
-name: 'cdk-watchful',
-license: 'MIT',
-repository: 'https://github.com/eladb/cdk-watchful.git',
-keywords: ['cloudwatch', 'monitoring']
-```
-
-All are pretty standard setup and nothing CDK-specific at this point. The `keywords` automatically gets 'cdk' so you don't
-need to specify it.
-
-## Dependencies
-
-### Depending on AWS CDK modules
-
-Next are getting CDK dependencies added:
-
-```typescript
-cdkVersion: '1.67.0',
-cdkDependencies: ['@aws-cdk/aws-ec2'],
-cdkTestDependencies: ['@aws-cdk/assert'],
-```
-
-`cdkDependencies` will add both dependencies and peerDependencies to your package.json file with a caret semver
-requirement (e.g. `^1.67.0`). CDK dependencies must be both direct and peer dependencies,
-see [this issue](https://github.com/aws/aws-cdk/issues/5064). You can set `cdkVersionPinning` to `true` to use a fixed
-version, but this means that any consumer of your library will have to use this exact CDK version.
-Likewise, `cdkTestDependencies` will add dependencies to the `devDependencies`.
-
-Additionally, you can add CDK dependencies using the methods:
-
-```typescript
-project.addCdkDependencies('aws-cdk/aws-sqs', 'aws-cdk/aws-sns');
-project.addCdkTestDependencies('aws-cdk/something-else');
-```
-
-> The `@aws-cdk/assert` library is already added to the `cdkTestDependencies` for you.
-
-### Depending on other modules
-
-If your library consumes other jsii modules, you should declare them thorugh the `deps` or `peerDeps` options. `deps` should be used if
-types from the consumed module is _not_ part of the public API of the library (the module is used as an implementation detail),
-while `peerDeps` _must_ be used if types from the consumed module are exported as part of your library's API. You can read more
-[here](https://github.com/aws/jsii/blob/master/docs/configuration.md#dependency-considerations).
-
-```ts
-deps: [ 'cdk-time-bomb' ]
-```
-
-A [dependabot](https://dependabot.com/) file will be added unless `dependabot` is set to 'false'.
-
-## Publishing
-
-As this is a [jsii project](./jsii.md), it will cross-compile to other languages.  You can set up
-any number of jsii target languages.
-
-```typescript
-  publishToNuget: {
-    dotNetNamespace: 'Acme.HelloNamespace',
-    packageId: 'Acme.HelloPackage'
-  },
-  publishToMaven: {
-    javaPackage: 'com.acme.hello',
-    mavenArtifactId: 'hello-jsii',
-    mavenGroupId: 'com.acme.hello'
-    serverId: 'github',
-    repositoryUrl: 'https://maven.pkg.github.com/example/hello-jsii',
-  },
-  publishToPypi: {
-    distName: 'acme.hello-jsii',
-    module: 'acme.hello_jsii'
-  },
-```
-
-[jsii-release](https://github.com/aws/jsii-release) is used for publishing, and requires uploading [Github project secrets](https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets) based on the repositories you wish to publish to:
-
-* npm - `NPM_TOKEN` ([docs](https://github.com/aws/jsii-release#npm))
-* .NET - `NUGET_API_KEY` ([docs](https://github.com/aws/jsii-release#nuget))
-* Java: `MAVEN_GPG_PRIVATE_KEY`, `MAVEN_GPG_PRIVATE_KEY_PASSPHRASE`, `MAVEN_PASSWORD`, `MAVEN_USERNAME`, `MAVEN_STAGING_PROFILE_ID` ([docs](https://github.com/aws/jsii-release#maven))
-* Python: `TWINE_USERNAME`, `TWINE_PASSWORD` ([docs](https://github.com/aws/jsii-release#pypi))
-  
-For help in getting these secrets for your project, read the [jsii-release](https://github.com/aws/jsii-release).
-  
-If you don't want to publish a particular package, do not include the `dotnet`, `java`, or `python` field.
-
-## Workflows
-
-Two workflows will be created as Github Actions:
-
-* The Build workflow - controlled by the `buildWorkflow` field. On a 'pull_request' or 'workflow_dispatch' the library
-will be built and checked for anti-tamper (ensure no manual changes to generated files).
-* The Release workflow - controlled by the `releaseWorkflow` field. On a push to `main` (overridden at
- `props.defaultReleaseBranch`) the library is built, anti-tampered, version bumped with a commit, pushed back to git,
- and then published to the configured artifact repositories (e.g. npm, pypi).
-
-## Tasks
-
-There are a number of package scripts that are created for you. Any of them can be overwritten using the `addScript*`
-methods.
-
-script|description
----|---
-start|starts an interactive command menu
-projen|regenerates the projen config. Run this if you edit .projenrc.js
-no-changes|a helper script to prevent unnecessary releases.
-bump|bumps the package version number
-release|bumps the library's version and pushes to origin
-projen:upgrade|upgrades the projen cli tool
-compile|builds the library and generates docs
-watch|compiles and then re-compiles of further changes
-package|runs jsii-pacmak to package your library for publishing
-test|compiles and runs automated tests
-test:watch|watches for file changes, re-compiles and re-tests
-test:update|update any test snapshots
-eslint|runs eslint against all `src` and `test` .ts files
-compat|checks for jsii compatibility. See [here](https://github.com/aws/jsii/tree/master/packages/jsii-diff) for more info.
-docgen|generate documentation
-
-As you develop your library you'll likely be using the `test:watch` command the most.
-
-## API Documentation
-
-Docs will be generated from [Typescript comments](https://typedoc.org/guides/doccomments/) and saved in the `API.md` file.
-Please review this file regularly and document your constructs liberally.
-
-## Project structure
-
-```
-.
-|--lib/ (build output)
-|--src/
-   |--index.ts
-|--test/
-   |--hello.test.ts
-```
-
-Source .ts files should reside in the `src` directory. Constructs should be exported from the index.ts file.
-Compiled files will be put in the `lib` directory. Tests are in the `test` directory. If you need additional
-resources that are packaged with your library, add those to a `resources` directory that is besides the `src` directory
-and modify your references accordingly:
-
-```typescript
-const thing = require('../resources/some-resource.json')
-```
-
-## Migrating existing projects
-
-Your existing CDK constructs likely have a different file structure than what this projen project expects. Projen projects
-are highly opinionated. There are a few expectations of this project you should modify your existing library to conform to:
-
-* All .ts files are expected to be in the `src/` directory. Existing constructs should all be moved there. However,
-you can override this directory by setting `srcdir`.
-* Compiled .js and .d.ts files will go into the `lib/` directory. This directory will be removed and rebuilt each build.
-Do not store source .ts files in your `lib/` or 'libdir'.
-* The entrypoint file for all constructs should be `src/index.ts`. If your existing library is not in the index.ts file,
-you can add the following to export it:
-
-```typescript
-export * from './our-s3-bucket'
-```

package/docs/awscdk.md

@@ -1,377 +0,0 @@
-# AWS Cloud Projects
-
-We support two types of projects for cloud development powered by the AWS Cloud
-Development Kit (AWS CDK): **apps** and **libraries**. Apps represent complete
-cloud applications while libraries vend constructs which can be consumed by
-other libraries or by apps. Libraries are published to public or internal
-package managers (npm, PyPI, Maven, NuGet, etc) while apps are deployed into AWS
-environments.
-
-This section describes features that are available in both cloud libraries and
-applications. See [AWS CDK Construct Library](./awscdk-construct.md) and [AWS
-CDK Applications](./awscdk-apps.md) for specific details about libraries and
-applications.
-
-## AWS Lambda Functions
-
-AWS Lambda is a serverless compute platform which executes short running code
-within a managed runtime environment.
-
-To define AWS Lambda functions, create a file with a `.lambda.ts` suffix under
-the source tree with AWS Lambda handler code.
-
-For example, say we create `src/resize-image.lambda.ts` with the following
-content:
-
-```ts
-export async function handler(event: any) {
-  console.log('I am resizing the image now!');
-}
-```
-
-Now run:
-
-```sh
-$ npx projen
-```
-
-You'll notice that a new file `src/resize-image-function.ts` has been added to
-your project. This is a generated source file which exports a construct named
-`ResizeImageFunction`. This construct is a subclass of
-`@aws-cdk/aws-lambda.Function`, bound to your specific handler. This means that
-you don't need to specify neither the `code` nor the `runtime` options when you
-add it to your app:
-
-```ts
-import { ResizeImageFunction } from './resize-image-function.ts';
-
-const handler = new ResizeImageFunction(this, 'ResizeImageFunction', {
-  env: {
-    FOO: '1234',
-  },
-
-  // all lambda options are supported...
-});
-```
-
-Under the hood, we also added a compilation task to your project which creates a
-.zip bundle for each handler. This bundle is created with
-[esbuild](https://github.com/evanw/esbuild) and includes only your handler code
-and all of its dependencies. This means that you can freely install and use any
-dependencies in your project and use them in your handlers. You can manually
-bundle your handler by executing the `bundle:HANDLER` or `bundle:watch:HANDLER`
-tasks.
-
-To customize this behavior for all functions, use `lambdaOptions` at the project
-level. For example:
-
-```ts
-const { awscdk } = require('projen');
-
-new AwsCdkConstructLibrary({
-  // ...
-  lambdaOptions: {
-    // target node.js runtime
-    runtime: awscdk.LambdaRuntime.NODEJS_18_X,
-
-    bundlingOptions: {
-      // list of node modules to exclude from the bundle
-      externals: [ 'aws-sdk' ],
-      sourcemap: true,
-    }
-  }
-});
-```
-
-You can also disable auto-discovery by setting `lambdaAutoDiscover` to
-`false` and then create explicitly add a `awscdk.LambdaFunction` component for
-each function in your project. This will allow you to perform more
-customizations as needed.
-
-```ts
-const { awscdk } = require('projen');
-
-const p = new AwsCdkTypeScriptApp({
-  lambdaAutoDiscover: false
-});
-
-new awscdk.LambdaFunction(p, {
-  entrypoint: 'src/foo.lambda.ts', // .lambda.ts extension is still required
-  runtime: aws_lambda.Runtime.NODEJS_12_X,
-});
-```
-
-## AWS Lambda Extensions
-
-An AWS [Lambda Extension][lambda-extensions-blog] is a way to integrate your
-preferred development, monitoring, observability, and governance tools with
-AWS Lambda.
-
-Functionally, AWS [Lambda Extensions][lambda-extensions-blog] are long-running
-executable files that reside in the `extensions` subdirectory of your code
-asset. AWS Lambda executes all extensions before starting your handler's main
-process. These AWS Lambda Extensions interact with your function's main process
-and the [Lambda Extension API][lambda-extensions-api] to integrate with tools
-outside the Lambda environment. Projen helps with bundling and preparing your
-code as reusable Lambda Layers.
-
-[lambda-extensions-blog]: https://aws.amazon.com/blogs/aws/getting-started-with-using-your-favorite-operational-tools-on-aws-lambda-extensions-are-now-generally-available/
-[lambda-extensions-api]: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html
-
-To create an AWS Lambda Extension with Projen:
-
-- Create a file in your project's source tree called
-  `my-extension.lambda-extension.ts`
-- Run `npx projen`
-- Projen will automatically discover this file, generating an AWS Lambda Layer
-  Version named `MyExtensionLayerVersion` in a file named
-  `my-extension-layer-version.ts`.
-- Now you can instantiate `MyExtensionLayerVersion` and add it to your Lambda
-  functions.
-
-Offical AWS extension examples are available in the [AWS Samples][ext-samples]
-repository.
-
-[ext-samples]: https://github.com/aws-samples/aws-lambda-extensions
-
-**Example of an extension:**
-
-A skeleton for a Lambda extension follows below. Comments with `TODO` describe
-locations where you can provide your custom functionality.
-
-```ts
-#!/usr/bin/env node
-// ^ Don't forget this shebang - Lambda executes the bundled version of this
-// file directly and doesn't otherwise know it's a node script.
-
-import { basename } from 'path';
-
-// This example uses the `got` HTTP client and assumes that you have included
-// `got` in your `devDependencies`. But, you can use any HTTP client you like.
-import got from 'got';
-
-/**
- * Your Lambda Extension's main loop
- */
-async function main() {
-  const extensionInfo = await registerExtension([
-    ExtensionEventType.SHUTDOWN,
-    ExtensionEventType.INVOKE,
-  ]);
-
-  // TODO: Put your initialization code here. You can do things like
-  // testing a connection to your external tooling here.
-
-  while (true) {
-    const event = await getNextEvent(extensionInfo.extensionId);
-
-    switch (event.eventType) {
-      case ExtensionEventType.SHUTDOWN:
-        // TODO: Do something when the lambda extension is being
-        // shut down. You might do things here like de-registering
-        // your extension from your external tooling.
-        return 0;
-
-      case ExtensionEventType.INVOKE:
-        // TODO: Do something every time your function is invoked,
-        // such as re-establishing a connection with your external
-        // tooling after the Lambda has thawed from a period of
-        // freezing due to inactivity.
-        break;
-
-      default:
-        console.log(`Unhandled event type ${event.eventType}`);
-    }
-  }
-}
-
-const EXTENSION_API_BASE_URL = `http://${process.env.AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension`;
-
-enum ExtensionEventType {
-  INVOKE = 'INVOKE',
-  SHUTDOWN = 'SHUTDOWN',
-}
-
-interface ExtensionEvent {
-  readonly eventType: ExtensionEventType;
-  // For complete event structures, see:
-  // https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html
-}
-
-async function registerExtension(events: ExtensionEventType[]) {
-  // Do not set a timeout on the GET call, as the extension can be suspended
-  // for a period of time until there is an event to return.
-  const res = await got.post(`${EXTENSION_API_BASE_URL}/register`, {
-    json: { events },
-    headers: {
-      'Lambda-Extension-Name': basename(__filename),
-    },
-  });
-
-  const header = res.headers['lambda-extension-identifier'];
-  const extensionId = Array.isArray(header) ? header[0] : header;
-  const json = JSON.parse(res.body);
-
-  return {
-    extensionId,
-    functionName: json.functionName as string,
-    functionVersion: json.functionVersion as string,
-  };
-}
-
-function getNextEvent(extensionId: string): Promise<ExtensionEvent> {
-  return got(`${EXTENSION_API_BASE_URL}/event/next`, {
-    headers: {
-      'Lambda-Extension-Identifier': extensionId,
-    },
-  }).json();
-}
-
-main()
-  .then(statusCode => {
-    process.exit(statusCode);
-  })
-  .catch(e => {
-    console.error(e);
-    process.exit(1);
-  });
-```
-
-## Integration Snapshot Tests
-
-Files in the `test/` tree with the `.integ.ts` suffix are recognized as
-*integration snapshot tests*.
-
-Each test is a simple CDK app (e.g. calls `app.synth()`) which exercises certain
-construct(s) within the project. A test is considered passing if the app can be
-successfully deployed.
-
-To create/update the snapshot, developers are expected to execute the task
-`integ:NAME:deploy` with AWS credentials for their personal development
-environment. This task will deploy the test app to their account. Upon
-successful deployment (i.e. the test passed), the snapshot will be captured and
-stored under a directory called `xxx.integ.snapshot` next to the test
-entrypoint. This directory should be committed to the repository.
-
-During builds (either local or within a workflow), the task `integ:NAME:assert`
-will be executed. This task synthesizes the test app and compares the output to
-the captured snapshot. The build will fail if the output differs.
-
-For each integration test, the following set of tasks are created:
-
-| Task                  | Description                                                                                                |
-| --------------------- | ---------------------------------------------------------------------------------------------------------- |
-| `integ:NAME:deploy`   | Deploys & destroys the test app and updates the snapshot.                                                  |
-| `integ:NAME:assert`   | Synthesizes the test app and compares it with the snapshot (this is the task that runs during build)       |
-| `integ:NAME:snapshot` | Synthesizes the test app and updates the snapshot (not recommended to use because it bypasses deployment). |
-| `integ:NAME:destroy`  | Destroys a previously deployed test app.                                                                   |
-
-### Writing test assertions
-
-You can write your test assertions as AWS Lambda handlers and use the AWS CDK
-[triggers][cdk-trigger-docs] module to execute them as part of the deployment.
-
-Here is an example of a test:
-
-```ts
-import { App,Stack } from '@aws-cdk/core';
-import { Trigger } from '@aws-cdk/triggers';
-import { ConstructUnderTest } from '../src';
-import { AssertSomeStuffFunction } from './assert-some-stuff-function.ts'; // <-- generated
-
-const app = new App();
-const stack = new Stack(app, 'Test');
-
-// this is the construct we want to test
-const testee = new ConstructUnderTest(stack, 'ConstructUnderTest');
-
-// execute a lambda handler with some assertions after all testee
-// resources are created
-new Trigger(stack, 'RunAssertions', {
-  executeAfter: [testee],
-  handler: new AssertSomeStuffFunction(stack, 'AssertSomeStuffFunction', {
-    env: {
-      URL: testee.url // <-- some reference to the created construct
-    }
-  }),
-});
-```
-
-[cdk-trigger-docs]:https://docs.aws.amazon.com/cdk/api/v1/docs/triggers-readme.html
-
-## Experimental `integ-runner` integration tests
-
-For TypeScript-based AWS CDK projects, Projen provides experimental support
-for using the [`integ-runner`][integ-runner] tool and [library][integ-library]
-for integration testing. To enable this feature, you specify
-`experimentalIntegRunner: true` in your project options.
-
-[integ-runner]: https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner
-[integ-library]: https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html
-
-
-```typescript
-import { awscdk } from 'projen';
-
-new awscdk.AwsCdkConstructLibrary({
-  // ...
-  experimentalIntegRunner: true
-});
-```
-
-After enabling experimental `integ-runner` support, all `integ.*.ts` files in
-the `test` directory will be automatically discovered and treated as
-integration tests. Projen will check that these integration tests match the
-committed snapshots at build-time, or whenever the test task is run.
-
-Projen also provides two new commands:
-
-`projen integ [...test names]` - Verifies integration test snapshots. If test
-names are provided, only the provided integration tests will be checked.
-Otherwise, all integration tests will be checked.
-
-`projen integ:update [...test names]` - Verifies integration test snapshots or
-updates the integration test snapshot by re-running the integration test on
-failure. Like `projen integ`, you may specify zero or more test names.
-
-> Tests are named based on their file path. For instance, with an integration
-> test contained in `test/r53writer/integ.ddbStreamHandler.ts`, the test name
-> is `r53writer/integ.ddbStreamHandler`, and you could update the test's
-> snapshot by running `projen integ:update r53writer/integ.ddbStreamHandler`.
-
-## Watch
-
-> Only relevant for app projects
-
-The `watch` command will use [cdk watch] in order to trigger deployments (with
-opportunistic hot-swapping) when source files or asset bundles are updated.
-`cdk.json` will automatically be configured to watch both source code changes
-and bundles, and rebuild bundles as needed.
-
-[cdk watch]: https://aws.amazon.com/blogs/developer/increasing-development-speed-with-cdk-watch/
-
-To start watching, set up your environment with AWS credentials and `AWS_REGION`
-pointing to your development AWS account and execute:
-
-```sh
-npx projen watch
-```
-
-This will:
-
-* Bundle your assets (if you have any).
-* Perform an initial deployment of your app into your development environment.
-* Start watching for changes.
-
-If you change a source file in your project, this change will be picked up by
-`cdk watch`, assets will be re-bundled and a hotswap deployment will be
-performed. For example, if you only change some AWS Lambda code, the CDK CLI
-will simply update the AWS Lambda service with the location of your new code
-bundle instead of going through an AWS CloudFormation deployment.
-
-## Roadmap
-
-* Additional bundling targets: web apps, ECS
-* Local execution for AWS Lambda, ECS containers, Step Functions
-* Support different provisioning engines (CloudFormation/Terraform) using Terraform L2 support
-* Generate types for strong-typing AWS Lambda/ECS environment bindings.

package/docs/build.md

@@ -1,55 +0,0 @@
-# Build
-
-Projen defines a standard way for building software through a fixed set of
-*build phases*. This is implemented via a set of [tasks](./tasks.md) defined in
-the `Project` base class.
-
-The `build` task spawns a set of sub-tasks which represent the various build phases:
-
-* `default` - this task is responsible to execute your projenrc and synthesize all project files.
-* `pre-compile` - runs before compilation (eg. bundle assets)
-* `compile` - compile your code (if needed)
-* `post-compile` - runs immediately after a successful compilation
-* `test` - runs tests
-* `package` - creates a distribution package
-
-To extend the build process, components and projects can use
-`project.projectBuild.xxxTask` and interact with the `Task` object (i.e.
-`project.projectBuild.postCompileTask.exec("echo hi")` will execute `echo hi` after
-compilation).
-
-> NOTE: the `build` task is locked. This means that any attempt to extend it
-> (i.e. call `spawn`, `exec`, `reset`, etc) will throw an exception. Instead of
-> extending `build`, just extend one of the phases. This ensures that phases are
-> always executed in the right order.
-
-## Build Workflow
-
-The `build` workflow is responsible to build your project when a pull request is
-submitted against it.
-
-### Self-mutation
-
-Projen synthesizes files that are part of your source repository. This means
-that when you change you projenrc file, and execute `projen`, other files in
-your repo may change as a result.
-
-This is also relevant in other situations where your build process _mutates_
-your repository. For example, if you use **snapshot testing**, your repository
-includes snapshots which represent expected test results. When your code
-changes, you will likely need to update those snapshots as well.
-
-To ensure that a pull request branch always represent the final state of the
-repository, you can enable the `mutableBuild` option in your project
-configuration (currently only supported for projects derived from
-`NodeProject`).
-
-When enabled, the PR build workflow (also called `build`) will push any modified
-files to the PR branch after a successful build, so that the branch will always
-reflect the most up-to-date version of all generated files.
-
-> This feature does not work for forks since it is impossible to safely push
-> changes to a fork from a PR build. If a PR is created from a fork of the
-> repository and there are build mutations, the PR build will fail (indicating
-> that it cannot push to the fork). To fix this, the branch needs to be updated
-> (same behavior as if mutable builds was disabled).

package/docs/bundling.md

@@ -1,30 +0,0 @@
-# Bundling
-
-The `Bundler` component (for Node.js projects) can be used to produce JavaScript
-bundles from source files.
-
-It is included by default in all projects derived from `NodeProject`.
-
-To customize, use `bundlerOptions`:
-
-```ts
-const project = new NodeProject({
-  esbuildVersion: '^0.13.13', // default to "latest"
-  assetsDir: 'resources', // defaults to "assets"
-});
-```
-
-To add bundles, call `bundler.addBundle()`:
-
-```ts
-project.bundler.addBundle('name-of-bundle', {
-  entrypoint: 'src/foo.ts',
-  target: 'node18',
-  platform: 'node',
-  bundlingOptions: {
-    externals: ['aws-sdk'], // modules not to include in bundles
-    sourcemap: true, // default is false
-    watchTask: false, // should we create a "bundle:watch" task for each bundle
-  }
-});
-```