feat: add support for resolve extensions esbuild setting

[JohnGrisham]

Support the ability to add custom resolution extensions via ESbuild settings. This is a feature of ESbuild and will allow for customization of lambda entrypoints. My team will be using this to support building different files based on the target environment we are deploying to.

Example:

myLambda.dev.ts
myLambda.prod.ts
myLambda.ts

When the environment we build for matches the extension of the file then that entrypoint will be used otherwise it will fallback to the default file resolutions in the order of our choosing. If the user of this plugin doesn't pass a resolveExtensions ESbuild setting then it will fallback to the array that was already defined by the repo.

https://esbuild.github.io/api/#resolve-extensions

Notes:

When using custom extensions as the entrypoint for lambdas AWS can complain if the file uses a custom extension. To resolve this I have also added a stripEntryResolveExtensions option to the plugin which will remove custom extension prefixes if they are used in the resolveExtensions list. This will result in files that have extensions like test.custom.js to be renamed as test.js in the eventual packed file. I'm open to suggestions if there is a better way to handle this or if this behavior should be the default for any custom extensions assuming the approach in this PR is approved.

[floydspace]

Hey @JohnGrisham, thank you for the contribution.
So this fix looks like allows to use of an entrypoint depending on the environment
Could you give more context what would be the difference between:
myLambda.dev.ts
myLambda.prod.ts
myLambda.ts

And as you are adding a new configuration property could you please add it in the docs with short explanation.
thanks you

[JohnGrisham]

@floydspace

Could you give more context what would be the difference between:
myLambda.dev.ts
myLambda.prod.ts
myLambda.ts

Practically for that example you could be connecting to a dev database in the dev lambda and a prod database in the prod lambda. Also in that example if neither of those lambdas were available or if the environment was not dev or prod then the default myLambda.ts could be used. This is assuming you structured your resolveExtensions array like this for example: ['myLambda.prod.ts', 'myLambda.dev.ts', 'myLambda.ts']. But this is more of a general example of how this might be used in most cases for our actual use case the company I contract for would be using this to control what code is shipped to either our commercial clients or our government clients. So we will actually be using myLambda.com.ts and myLambda.gov.ts and controlling the resolveExtensions array to include only the extensions that match our environment at build time. For example if building for commercial clients we would do something like: ['myLambda.com.ts', 'myLambda.ts'], by doing this we could omit any government code that we do not want to be used for commercial purposes. This seems to work for both entrypoints and file imports inside those entrypoints from my testing with these changes.

[JohnGrisham]

@floydspace I have made the requested changes, please let me know if there is anything else I can clear up or change.

[floydspace]

LGTM, I gonna merge it, hope it will be useful for others

thank you for contribution

[github-actions]

🎉 This PR is included in version 1.50.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀