You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This work is partially done already, but we are open to changes so I want an issue for potential feedback and to track any remaining work.
The main idea is that we want users to provide information (i.e. hooks and functions) programmatically, meaning we need to define an API in which they can do that. As a part of the hooks feature, we settled on a "built-in" module named @azure/functions-core. See here for some more background. Here is example usage as described in #548:
I really like the more functional approach, as it fits better into the current JS ecosystem. Having as much tasks done by code (referring to #569) as possible should be the goal as well of getting rid of the requirement of having multiple separate files (we already have function.json, host,json, extensions, etc.) and of course not introducing new like the startup one.
The JS/TS world already has a lot of options regarding modularization, I think it should be decided by the developer which way he wants to go with that.
This work is partially done already, but we are open to changes so I want an issue for potential feedback and to track any remaining work.
The main idea is that we want users to provide information (i.e. hooks and functions) programmatically, meaning we need to define an API in which they can do that. As a part of the hooks feature, we settled on a "built-in" module named
@azure/functions-core
. See here for some more background. Here is example usage as described in #548:The main alternative we have considered is for the user to return hooks/functions in a startup file as a module export. Example usage described here.
Remaining work
@types/azure_functions-core
packagerequire
instead ofimport
(workaround here)The text was updated successfully, but these errors were encountered: