-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(nuxt): Add entrypointWrappedFunctions
to define async wrapped server functions
#14104
Conversation
75db7b5
to
031e219
Compare
size-limit report 📦
|
packages/nuxt/src/common/types.ts
Outdated
* The `asyncFunctionReExports` option is only relevant when `dynamicImportForServerEntry: true` (default value). | ||
* | ||
* As the server entry file is wrapped with a dynamic `import()`, previous async function exports need to be re-exported. | ||
* The SDK detects and re-exports those exports (mostly serverless functions). This is why they are re-exported as async functions. | ||
* In case you have a custom setup and your server exports other async functions, you can override the default array with this option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: Maybe we can rewrite this a bit, to a perspective of somebody who does not have deep understanding of all of this :D
* The `asyncFunctionReExports` option is only relevant when `dynamicImportForServerEntry: true` (default value). | |
* | |
* As the server entry file is wrapped with a dynamic `import()`, previous async function exports need to be re-exported. | |
* The SDK detects and re-exports those exports (mostly serverless functions). This is why they are re-exported as async functions. | |
* In case you have a custom setup and your server exports other async functions, you can override the default array with this option. | |
* By default (unless you configure `dynamicImportForServerEntry: false`) the SDK will try to wrap your application entrypoint with a dynamic `import()` to ensure all dependencies can be properly instrumented. | |
* | |
* By default, the SDK will wrap the default export as well as a `handler` or `server` export from the entrypoint. If your application has a different main export that is used to run the application, you can overwrite this by providing an array of export names to wrap. | |
* Any wrapped export is expected to be an async function. |
packages/nuxt/src/module.ts
Outdated
asyncFunctionReExports: moduleOptionsParam.asyncFunctionReExports | ||
? moduleOptionsParam.asyncFunctionReExports | ||
: ['default', 'handler', 'server'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super-l: I find it slightly easier to read:
asyncFunctionReExports: moduleOptionsParam.asyncFunctionReExports | |
? moduleOptionsParam.asyncFunctionReExports | |
: ['default', 'handler', 'server'], | |
asyncFunctionReExports: moduleOptionsParam.asyncFunctionReExports || ['default', 'handler', 'server'], |
@@ -111,16 +111,16 @@ describe('constructFunctionReExport', () => { | |||
const result2 = constructFunctionReExport(query2, entryId); | |||
|
|||
const expected = ` | |||
async function reExport(...args) { | |||
async function reExport0(...args) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m: Can we also have a test here to show that it does not change/wrap an export that does not match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would require changing a lot of logic in the code. The here tested function constructFunctionReExport
is only getting the input from the query parameters and creating a function for each query param.
The part, where those query params are actually added is here:
const functionsToExport = flatten(Object.values(moduleInfo.exportedBindings || {})).filter(functionName =>
asyncFunctionReExports.includes(functionName),
);
One thing I could do is extracting this part as a function to test this step as well. But as adding the query params and generating the function code happen in two different Rollup hooks, I cannot combine those two things in one function or test.
I'd design the API as follows: interface WhateverOptions {
entrypointExportOverrides: {
asyncFunctions: string[];
functions: string[];
}
} |
We cannot wrap functions this way though, can we? Or we'd turn the sync function into an async one (which we already do anyhow right now if we'd match)? |
Right, I feel like we need a mechanism that will just exclude certain exports from the whole shebang |
I think the idea is (Sigrid correct me if I'm wrong): We do not wrap anything, generally, except the exports defined in this array (all of which are assumed to be async functions). If you do not want to wrap anything you could define |
I think the suggestion of @lforst makes sense because if nothing is re-exported it's not exported at all. The problem here is that |
84ff708
to
b8a73ca
Compare
asyncFunctionReExports
to define re-exported server functionsentrypointWrappedFunctions
to define async wrapped server functions
Based on this PR: #14086
We get the names of the exports with Rollup's
exportedBindings
, but we cannot know whether this is a function or something else. As we need to re-export serverless functions for Netlify, Vercel and so on, an educated guess is made that'default', 'handler', 'server'
are potential serverless functions that need to be wrapped by Sentry and re-exported.In case users experience issues, this can be changed with
entrypointWrappedFunctions
.All other exports are exported as they were before.