feat: expose generatedFunctions to consumers
#6525
Conversation
|
This pull request adds or modifies JavaScript ( |
|
This pull request adds or modifies JavaScript ( |
| const result: Record<string, GeneratedFunction[]> = {} | ||
|
|
||
| for (const func of generatedFunctions) { | ||
| // eslint-disable-next-line @typescript-eslint/no-unnecessary-condition | ||
| result[func.generator.name] = result[func.generator.name] || [] |
There was a problem hiding this comment.
FWIW this is because given f: Record<string, Foo> with noUncheckedIndexAccess disabled, f[string] results in the type Foo, not Foo | undefined. ESLint is being pedantically correct here (arguably).
You can avoid the suppression this way:
| const result: Record<string, GeneratedFunction[]> = {} | |
| for (const func of generatedFunctions) { | |
| // eslint-disable-next-line @typescript-eslint/no-unnecessary-condition | |
| result[func.generator.name] = result[func.generator.name] || [] | |
| const result: Record<string, GeneratedFunction[] | undefined> = {} | |
| for (const func of generatedFunctions) { | |
| result[func.generator.name] = result[func.generator.name] || [] |
There was a problem hiding this comment.
But that's not the type I want to return. I don't want consumers of this method to think that some keys will have the value undefined, because that shouldn't be the case.
There was a problem hiding this comment.
It's problematic either way. It's just a limitation of TypeScript's type system without noUncheckedIndexAccess:
- With your type, a user dereferencing
result['kjfandsakj']will getGeneratedFunction[]. - With my type, a user iterating over
result's own keys and dereferencingresult[key]will getGeneratedFunction[] | undefined.
Both cases are not what we intend to express 😞. The latter is safer, but way more annoying.
https://claude.ai/share/a8fbb3cb-bd72-4761-a2e6-1d55e876889c
The only good solution is enabling noUncheckedIndexAccess.
(To be clear, this is absolutely nonblocking tangential rambling—please proceed with merging!)
Summary
Follow-up to #6487, exposing the list of generated functions to consumers of
@netlify/buildvia the default export and thestartDevmethod.This will be used by the CLI to learn about any functions that were generated and that need to be added to the list of function paths.
I ended up changing the internals a little bit such that we keep passing
returnValuesaround internally, but what we expose externally is ageneratedFunctionsobject. The generation of this object has been moved to a separate file, which is now reused by the functions core step and the logic that prints functions. This is for unification and simplicity purposes, no functional changes are expected.A picture of a cute animal (not mandatory, but encouraged)
🦅