Fix watch mode not reloading after files with compiler errors are fixed #27
Conversation
| @@ -7,6 +7,8 @@ This changelog documents the changes between release versions. | |||
| ## [Unreleased] | |||
| Changes to be included in the next upcoming release | |||
|
|
|||
| - Fixed watch mode not reloading after files with compiler errors are changed [#27](https://github.com/hasura/ndc-nodejs-lambda/pull/27) | |||
| export type Configuration = { | ||
| functionsSchema: FunctionsSchema | ||
| runtimeFunctions: RuntimeFunctions | ||
| }; |
There was a problem hiding this comment.
Can you pass in functions in config, or conversely, export them?
There was a problem hiding this comment.
Config is purely an internal type now, it doesn't really represent precisely what the user configures any more. The files on disk do.
RuntimeFunctions needed to move into config from state because importation (ie require) needs to be run before schema inference, as per the PR description. And schema inference can't be done in state, since getSchema doesn't access state.
There was a problem hiding this comment.
Ah yeah that makes sense. I guess the name still throws me off but the implementation is obviously fine.
There was a problem hiding this comment.
Yeah, I agree. I think the State and Configuration style of doing things is kinda a holdover from the old configuration server. In practice now, we really could combine State and Configuration in the SDK and let the connector authors draw a distinction inside the one type if they want. c'est la vie.
This PR fixes a bug in watch mode, where, if you had compile errors in your functions TypeScript code, after fixing the compile errors, the connector would not be restarted to reload your changes. Now, when you change your (broken) files, the connector will reload and retry to compile your code.
This was caused by an optimisation where we performed schema inference and if we got TS compiler errors, we skipped
require-ing the function code into the app. We did this because we wanted to avoid compiling the code twice, and also because the compilation viarequirewould produce extra error output in the terminal. Unfortunately, because we skippedrequire, we skipped the registration of the function code into the hot-reloading watching system provided byts-node-dev.To fix this, I've removed this optimisation. We now always
requirethe functions code, and we letts-nodedo a full type-checked compile (not just a transpile), so if it fails, we get the full compiler errors and output those to the terminal and then skip schema inference. If there are no compiler errors and the code successfully imports viarequire, we then do schema inference.