Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for resolve extensions esbuild setting #510

Merged
merged 3 commits into from
Dec 5, 2023

Conversation

JohnGrisham
Copy link
Contributor

@JohnGrisham JohnGrisham commented Dec 1, 2023

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
Copy link
Owner

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@floydspace
Copy link
Owner

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

thank you for contribution

@floydspace floydspace merged commit 31dd88f into floydspace:master Dec 5, 2023
3 checks passed
Copy link

github-actions bot commented Dec 5, 2023

🎉 This PR is included in version 1.50.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@JohnGrisham JohnGrisham deleted the feat-resolve-extensions branch December 5, 2023 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants