fix: parse TOML 1.1 manifests

[JP-Ellis]

Cargo accepts TOML 1.1 in Cargo.toml, including inline tables that span several lines:

tokio = {
  version = "1",
  features = ["macros", "rt-multi-thread"],
}

getManifest parses the manifest with the bundled js-toml 1.0.2, which only supports TOML 1.0, so cdk synth fails with a SyntaxParseError before bundling starts. js-toml has parsed TOML 1.1 since 1.2.0. Because js-toml is a bundled dependency, consumers cannot override the version themselves.

Changes

• Bump the bundled js-toml from ^1.0.2 to ^2.0.1. The 2.x breaking changes only affect how dates and times are represented. getManifest reads package.name, bin and workspace.members, which are all strings. 2.0.0 is deprecated upstream, hence ^2.0.1.
• Drop the chevrotain resolution added in fix: resolve lodash-es prototype pollution vulnerability (GHSA-xxjr-mmjv-4gpg) #88 for GHSA-xxjr-mmjv-4gpg. js-toml 2 depends on chevrotain 12, which no longer depends on lodash-es. Removing the override restores projen's default resolutions.
• Add a TOML 1.1 fixture and a getManifest test. The test fails on js-toml 1.0.2 and passes with this change.

Testing

• npx projen test: all 23 tests pass.
• npx projen package:js: the tarball bundles js-toml 2.0.1.
• Installed the tarball into a CDK app whose Cargo.toml uses a multi-line inline table. cdk synth now gets past manifest parsing.

Related

cargo-lambda/cargo-lambda#940 fixes the same problem in the cargo-lambda CLI, which parses the manifest with the toml crate during bundling. A CDK app with a TOML 1.1 manifest needs both fixes: synthesis fails here first, then bundling fails in cargo-lambda.

AI Disclosure

This PR was substantially written by AI, but was reviewed manually by a human.

[JP-Ellis]

Please let me know if there's anything else you would like me to do. I'm keen to have TOML 1.1 supported by cargo-lambda.