@architect/sandbox with @architect/plugin-typescript

[cayter]

I'm currently using @architect/plugin-typescript with all my lambda TS functions and sharing the common code in src/shared/*.ts. Upon saving the lambda TS functions, it would re-compile fine, but when saving the common code in src/shared folder, it just won't re-compile or restart the sandbox automatically which I'd need to re-save the lambda functions to trigger the re-compile to see the updated change. I checked the sandbox watcher source code, it seems it doesn't have logic to restart the sandbox when there's a change in src/shared path. Is this expected?

[ryanblock]

This is expected, yes – and no, we would not want to restart the entire Sandbox due to a code change in src/shared. As for the TS plugin, it doesn't have any awareness of which Lambdas use your shared code, and which do not.

Moreover, the plugin doesn't have any general awareness of your particular shared code affordances, as that's something that's left up to your specific implementation. For example, you may use src/shared (the normal Architect convention), but someone else may use src/ts/shared, or src/ts-shared, etc. to separate their shared TypeScript from shared JavaScript. (See also: https://github.com/architect-examples/typescript-example#built-in--ts-friendly-approaches-to-shared-code)

So to get back to the problem at hand, I do think it makes sense to trigger some recompiles given the above circumstances; I wonder if perhaps we should look at your tsconfig paths setting and if we detect a file change in something specified in paths, perhaps recompile the whole project?

[cayter]

Thanks for the quick reply. The reason I think a sandbox restart makes sense is mainly due to we don't have to take care of the dependency graphs, i.e. knowing which handlers are using the shared TS file that is being updated and only trigger re-compile the handlers that are importing the shared TS file. Hence, restarting the sandbox should be the fastest way since we're already using esbuild underneath.

I wonder if perhaps we should look at your tsconfig paths setting and if we detect a file change in something specified in paths, perhaps recompile the whole project?

This should work, 'cause right now I'm using tsconfig's path alias for src/shared. And I assume recompile the whole project here means without restarting the sandbox but re-trigger esbuild compile on all the handlers right?

[ryanblock]

Just to be clear, we don’t want to restart the Sandbox unless absolutely necessary. It is generally pretty fast, because we try hard to make it fast, but it’s still quite expensive and you’ll disconnect WS clients, lose whatever data is in Dynamo, etc. Re/starting the Sandbox also recompiles the whole TS project, which it sounds like is what’s actually desired.

Recompiling the whole project is, comparatively speaking, much less expensive, in addition to being the more appropriate action.

That said I’m open to other ideas, especially for folks not using paths!

[cayter]

In this case, I think tsconfig's paths alias sounds good to me since the plugin needs to know which path to trigger the re-compile. Or if we need to accommodate use cases that aren't using tsconfig's paths, we can resort to configure the watch path in app.arc's @plugins section?

[cayter]

@ryanblock Would the functionality be added to @architect/plugin-typescript or @architect/sandbox? CMIIW, I think this is the place we need to update? Here's the PR I've tested with my project locally. Works well.