Description of your changes

This PR addresses the requirement of adding the new Parameters utility to the release process. This utility exports its components in a slightly different way than the other existing utilities and for this reason it requires an ad-hoc process for packaging.

Based on the current folder structure and configs, whenever a package is built (npm run build) the contents end up in a folder called lib that resides within the package folder (i.e. packages/parameters/lib). After that, when running npm pack as part of the npm publish command, the content of the lib folder is package in a tarball and published to npm with a similar folder structure:

index.js
lib/appconfig/index.js
lib/ssm/index.js
...

As previously mentioned, the Parameters utility has a different way of exporting its internals. This is due to the fact that we want to allow users to selectively import a provider without having to import all others. So for instance, if a user wants to use the SSMProvider, their code should not also import the DynamoDBProvider, which also brings in its own dependencies.

To achieve this, instead of providing a main entry point at @aws-lambda-powertools/parameters (with index.js), we are providing more scoped imports like:

• @aws-lambda-powertools/parameters/ssm
• @aws-lambda-powertools/parameters/appconfig
• etc.

This type of imports is not compatible with the current folder structure. The current folder structure would allow to import packages with @aws-lambda-powertools/parameters/lib/ssm (**notice the lib in the path).

To instead allow cleaner imports that also don't expose our internal folder structure, we need to take two steps:

• instruct the npm pack command to point to the lib folder instead of the package folder
• patch the following fields within the lib/package.json file
  • "main": "./lib/index.js" -> "main": "./index.js"
  • "types": "./lib/index.d.ts" -> "types": "./index.d.ts"

To do so, this PR introduces the following changes:

• add a publishConfig.directory field supported by lerna that points to the lib folder
• add a prepack script to the package that patches the package.json file inside the lib folder.

The script is added to the .github/scripts folder and temporarily copied on demand during the prepack lifecycle event.

Given that we now have a script that runs right before the package is packed, I took the liberty of introducing two additional optimizations/changes:

• clean up the content of the package.json so that only the fields needed for npm are included (i.e. exclude scripts and other internal ones)
• patch the version number to add a -beta suffix to both the package's package.json file and the one inside lib, so that the number is picked up during packaging and publishing

Note that lerna already runs git restore at the end of the publishing process, so the patched version number is restored to a non beta one, which will allow the next versioning to increase the version normally. The version of the beta packages will be aligned with the GA packages, except for the presence of a -beta suffix. So for instance, the release after this one, will likely be 1.8.1-beta, 1.9.0-beta etc., based on the semantic versioning of all the packages.

The patching script is written in a way that can be reused for other packages. Once we release the next major version of all the utilities, we'll likely apply the same export flattening to all of them.

How to verify this change

I have verified this change by running a local npm registry (verdaccio) and running the lerna version and lerna publish commands, and then verified that the published artifact complies with the expected structure.

Related issues, RFCs

Issue number: #1040

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.