feat: add functions.generate util
#6487
Conversation
|
This pull request adds or modifies JavaScript ( |
There was a problem hiding this comment.
The changes look good as they are, less missing tests. Let me know if you'd like a re-review once you add those.
I do wonder if exposing a method(s) for registering generated functions on the context (e.g. addGeneratedFunction and/or addGeneratedFunctions) might be a better API?
A method feels more consistent with the rest of the build hooks API, feels a little more intentional/easier to document, and is a more backward-compatible change. (Specifically, I'm wondering how many consumers are e.g. returning a promise from a build hook and counting on the current behavior of build resolving the promise but completely ignoring the return value.)
That said: I don't feel strongly about this, I don't understand if you have a particular reason for preferring a return value, and this is admittedly pretty edge casey. The likelihood that someone is returning a value with this property on it is low, but this would have higher potential for trouble as we expand the return-value API.
| @@ -221,6 +235,10 @@ const hasFunctionsDirectories = async function ({ | |||
| return await pathExists(frameworkFunctionsSrc) | |||
| } | |||
|
|
|||
| const getGeneratedFunctions = (returnValues: Record<string, ReturnValue>) => { | |||
| return Object.values(returnValues).flatMap((returnValue) => returnValue.generatedFunctions || []) | |||
There was a problem hiding this comment.
Are we defaulting returnValues to a non-nil value somewhere? I see on the type that we define this property as optional, but I don't see the code path where we're handling void returns from the build hook.
I'm probably just missing this somewhere in the prop drilling, but thought I'd point it out.
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
Yeah, I agree a method would be nicer, and this was my first choice. I ended up going for a return value because that felt simpler, as the communication mechanism between Netlify Build and the plugins is far from trivial, with parent/child process communicating over IPC messages. At first I thought that a method call would need to be an out-of-band message as a separate event, but that's not really the case. In 480f66b I've added a new |
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
eduardoboucas
changed the title
functions.generate util
| for (const id in returnValues) { | ||
| if (returnValues[id].generatedFunctions && returnValues[id].generatedFunctions.length !== 0) { |
There was a problem hiding this comment.
nit
| for (const id in returnValues) { | |
| if (returnValues[id].generatedFunctions && returnValues[id].generatedFunctions.length !== 0) { | |
| for (const {generatedFunctions} of Object.values(returnValues)) { | |
| if (generatedFunctions?.length !== 0) { |
|
This pull request adds or modifies JavaScript ( |
Summary
This PR implements support for build plugins to generate Netlify Functions that are automatically included in the build process without
requiring file copying. This introduces a new
utils.functions.generate()method that allows plugins to register function files that theymanage directly.
Technical Implementation
Plugin-side changes:
functions.generate(mainFile)method to the utils object available to pluginsBuild system changes:
Type safety:
generatemethod