Skip to content

Commit eadbe2f

Browse files
rnagrnag
authored
v1.2.0: add "skip build" option and functionality (#14)
* package version updates * allow options to skip build step * fix so we don't build when `cdk destroy` etc. is run * update Settings with `SKIP_BUILD` * check for `build` context value passed when invoking `cdk` * update sample CDK apps to use `swc` when deploying `cdk` -- minor optimization * update docs * update CHANGELOG.md etc * Update CHANGELOG.md * update docs
1 parent 73b8cdb commit eadbe2f

File tree

21 files changed

+21306
-21510
lines changed

21 files changed

+21306
-21510
lines changed

‎CHANGELOG.md‎

Lines changed: 26 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -11,17 +11,40 @@ Possible header types:
1111

1212
## [Unreleased]
1313

14+
## v1.2.0 (2023-02-03)
15+
16+
### Bug Fixes
17+
18+
- `RustFunction` should not execute `cargo lambda` when certain `cdk` sub-commands are invoked, such as:
19+
- `destroy`
20+
- `list`
21+
- etc.
22+
- _Potential_ bug-fix (unconfirmed): The library should not execute `cargo lambda` when a project has multiple stacks, and the stack being deployed doesn't include any `RustFunction` constructs.
23+
24+
### Features
25+
26+
- Add parameters to `Settings`:
27+
- `SKIP_BUILD`
28+
- Update docs to mention how to _skip_ the build step by passing in the `build` context flag when invoking a `cdk` command. For example:
29+
```shell
30+
cdk synth -c build=0
31+
```
32+
- Update developer docs used for local testing, as I determined a newish approach with `npm link` can be used, as outlined in [this article].
33+
- Enable `swc` in all sample CDK apps, in order to improve the overall [performance of `ts-node`](https://typestrong.org/ts-node/docs/performance) when `cdk` is run.
34+
35+
[this article]: https://stackoverflow.com/a/18778516/10237506
36+
1437
## v1.1.3 (2022-03-28)
1538

16-
## Breaking Changes
39+
### Breaking Changes
1740

1841
- Switch to use [`cargo-lambda`] -- which abstracts away `cargo-zigbuild` -- for
1942
building Rust code; technically this is not a _breaking_ change, but it **will** require
2043
the package to be installed with `cargo`.
2144

2245
[`cargo-lambda`]: https://crates.io/crates/cargo-lambda
2346

24-
## Features
47+
### Features
2548

2649
- [zig] can now be installed via the `--save-optional` flag when installing this package:
2750
```shell
@@ -35,7 +58,7 @@ Possible header types:
3558

3659
## v1.0.0 (2022-03-21)
3760

38-
## Breaking Changes
61+
### Breaking Changes
3962

4063
- Switch to use [`cargo-zigbuild`] -- instead of `cross` -- for building Rust code.
4164
- Switch the default build architecture from `x86_64` to `arm64`; this package now uses **aarch64-unknown-linux-gnu** as the default build target for AWS Lambda functions, mainly as I've found this architecture to be slightly more performant in general use cases.

‎README.md‎

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -290,12 +290,14 @@ import { Settings } from 'rust.aws-cdk-lambda';
290290
291291
Below are some useful _global_ defaults which can be set for all Rust Lambda Functions in a CDK app.
292292
293-
| Name | Description |
294-
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
295-
| `BUILD_INDIVIDUALLY` | Whether to build each executable individually, either via `--bin` or `--package`. |
296-
| `DEFAULT_LOG_LEVEL` | Log Level for non-module libraries. Note that this value is only used when `RustFunctionProps.setupLogging` is enabled. Defaults to `warn`. |
297-
| `MODULE_LOG_LEVEL` | Log Level for a module (i.e. the executable). Note that this value is only used when `RustFunctionProps.setupLogging` is enabled. Defaults to `debug`. |
298-
| `WORKSPACE_DIR` | Sets the root workspace directory. By default, the workspace directory is assumed to be the directory where `cdk` was invoked.<br><br>This directory should contain at the minimum a `Cargo.toml` file which defines the workspace members. |
299-
| `FEATURES` | A list of features to activate when compiling Rust code. These must also be added to the `Cargo.toml` file. |
300-
| `BUILD_ENVIRONMENT` | Key-value pairs that are passed in at compile time, i.e. to `cargo build` or `cargo lambda`. This differs from `environment`, which determines the environment variables which are set on the AWS Lambda function itself. |
301-
| `EXTRA_BUILD_ARGS` | Additional arguments that are passed in at build time to both `cargo lambda`. For example, [`--all-features`]. |
293+
| Name | Description |
294+
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
295+
| `BUILD_INDIVIDUALLY` | Whether to build each executable individually, either via `--bin` or `--package`. |
296+
| `DEFAULT_LOG_LEVEL` | Log Level for non-module libraries. Note that this value is only used when `RustFunctionProps.setupLogging` is enabled. Defaults to `warn`. |
297+
| `MODULE_LOG_LEVEL` | Log Level for a module (i.e. the executable). Note that this value is only used when `RustFunctionProps.setupLogging` is enabled. Defaults to `debug`. |
298+
| `WORKSPACE_DIR` | Sets the root workspace directory. By default, the workspace directory is assumed to be the directory where `cdk` was invoked.<br><br>This directory should contain at the minimum a `Cargo.toml` file which defines the workspace members. |
299+
| `FEATURES` | A list of features to activate when compiling Rust code. These must also be added to the `Cargo.toml` file. |
300+
| `BUILD_ENVIRONMENT` | Key-value pairs that are passed in at compile time, i.e. to `cargo build` or `cargo lambda`. This differs from `environment`, which determines the environment variables which are set on the AWS Lambda function itself. |
301+
| `EXTRA_BUILD_ARGS` | Additional arguments that are passed in at build time to both `cargo lambda`. For example, [`--all-features`]. |
302+
| `SKIP_BUILD` | Whether to skip building Rust Lambdas -- e.g. skip the compile step with `cargo lambda`.<br><br>Alternatively, this can be set in the `build` context, when invoking `cdk` -- for example:<br>`$ cdk synth -c build=[T \| true \| 1 \| Y \| yes \| ok \| on]`<br>Any values other than the listed evaluate to `false`. So, this would skip the build step on `synth`:<br>`$ cdk synth -c build=0` |
303+
| |

‎cdk-examples/README.md‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -64,6 +64,8 @@ echo '\n# Rust lambda build directory\n.build' >> .gitignore
6464

6565
## Local Development and Testing
6666

67+
> _Note_: See the [New Approach](#new-approach) below which obviates the need to update the `import` statements.
68+
6769
In case it's desirable to uncomment the following import in the `lib/` folder of a sample CDK app, for local testing purposes:
6870

6971
```ts
@@ -87,3 +89,53 @@ For example, here are the important ones you'd need to verify:
8789
├── [email protected]
8890
├── [email protected]
8991
```
92+
93+
### New Approach
94+
95+
As per [this article](https://stackoverflow.com/a/18778516/10237506) I found that explains how a local module can be installed with `npm link`, this is a slightly different approach to commenting out and then un-commenting an `import` statement as mentioned above.
96+
97+
This does also have a few unavoidable side-effects, but hopefully such a method should yield an overall better (developer) experience.
98+
99+
Here then, is the updated approach which leverages `npm link` under the hood to locally install an NPM module.
100+
101+
First, `cd` into the local directory of a sample CDK app.
102+
103+
Within this folder, run the npm script `link` (alias: `l`) to automatically link to the local `rust.aws-cdk-lambda` module -- i.e. the project folder two levels up:
104+
105+
```shell
106+
npm run l
107+
```
108+
109+
If all is well, you should see that the _linking_ is successful.
110+
111+
To confirm:
112+
113+
```shell
114+
npm list
115+
```
116+
117+
The result should be something like:
118+
119+
```plaintext
120+
...
121+
├── [email protected] -> ./../..
122+
...
123+
```
124+
125+
That means everything is set up correctly! CDK code should reference the definitions under `../../dist/`, i.e. under the root folder.
126+
127+
Next -- open a new terminal window, and from the project root folder `$root`, run the following command:
128+
129+
```shell
130+
npm run watch
131+
```
132+
133+
This will listen for any changes to the project TypeScript code, and automatically run `tsc` to down-compile it to JS code, which it places in the `dist/` folder.
134+
135+
These changes will also be reflected in the sample CDK project, thanks to `npm link` which was run earlier.
136+
137+
To _unlink_ the local module and use the remote one installed as a dependency listed in the `package.json`, simply run the following from the root of a sample CDK app:
138+
139+
```shell
140+
npm run ul
141+
```

0 commit comments

Comments
 (0)