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

fix: get artefact and metafile paths from Serverless API #2

Merged
merged 1 commit into from
Feb 11, 2022

Conversation

smbkr
Copy link
Contributor

@smbkr smbkr commented Feb 9, 2022

Gets the paths to the metadata file and the zipped artifact from the FunctionDefinitionHandler object exposed by the Serverless API.

The current release fails for me where e.g. the function name in Serverless is 'myFunction' but the file path is myFunctionHandler.ts, as the current implementation assumes the filename and function name are the same which may not be the case. ESBuild outputs the metafile as ${sourceFileName}-meta.json.

The current implementation also assumes the full function name (stack-stage-function) is the same as the output zip file, however in my case the output file is just the function name sans stage and stack. This PR fixes this by getting the path from the Serverless API.

Fixes #1

.find(fullFunctionName => fullFunctionName.endsWith(functionName));

if (functionZipName === undefined) {
const fullZipPath = slsFunction.package?.artifact;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like /home/me/projects/foo/.serverless/myfunction.zip

@@ -57,6 +56,7 @@ async function bundleVisualizer(this: ServerlessAnalyzeBundlePlugin): Promise<vo

return;
}
const functionZipName = parse(fullZipPath).base;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just the file and ext, e.g. myfunction.zip

)[0];
const allFiles = getAllFiles(`${TEMP_DIR_LOCATION}`);
const metafileName = allFiles.filter(fileName => {
const handlerPath = (slsFunction as FunctionDefinitionHandler).handler.split('.')[0];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will return the value configured in serverless.yml for the function handler, e.g. src/handlers/foo.main. We use split to get just up to the . as the part that follows is the exported function name

Comment on lines +75 to +82
if (!metafileName) {
this.serverless.cli.log(
`🤯 Analyze failed: function ${functionName} metadata was not found`,
'ServerlessAnalyzeBundlePlugin',
{ color: 'red' },
);

return;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add explicit error handler here, since I was getting uncaught errors prior to fixing this.

@smbkr smbkr changed the title fix: get artifact and metafile paths from sls function object fix: get artifact and metafile paths from Serverless API Feb 9, 2022
@smbkr smbkr changed the title fix: get artifact and metafile paths from Serverless API fix: get artefact and metafile paths from Serverless API Feb 9, 2022
Gets the paths to the metadata file and the zipped artifact from the
FunctionDefinitionHandler object exposed by the Serverless API. This
makes the plugin work correctly when e.g. the handler path is something
like `src/myFunctionHandler.main`.

Previously this was failing for me where e.g. the function name in
Serverless was 'myFunction' but the file path was
`myFunctionHandler.ts`.
Copy link
Owner

@adriencaccia adriencaccia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @smbkr !
Thanks for the issue, the explanation and the fix in this PR 🥳

I am both amazed and grateful by the quality of your contribution !

I tested your fix with both serverless-esbuild@1.17.1 and serverless-esbuild@1.24.1, it works for both.

I will release your fix in a 1.0.6 version.

@adriencaccia adriencaccia merged commit e164344 into adriencaccia:main Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants