Hi folks I have a fair…

Hi folks - I have a fairly massive yarn-based repo of around 122 typescript projects, largely pointing into 5 or so top level artifacts. I’m struggling, in yarn, in dealing with dependencies, especially around zips generated for lambdas. Does nx solve this problem the way someone intimately familiar with make, scons, cmake, etc would expect? I want to have the confidence that if I change a file in a lambda, the resulting artifact in a different project that depends on that zip file will have an updated zip file available to it. Is this something that nx will handle?

Responses:

You have libs and applications in NX So I guess your lambdas will be the applications in your case. You can have X apps === X lambdas as example.

Nx will tell you which lambda needs to be redeployed if a lib or the code in the lambda self is changing.

So I guess if I understand you correctly. Yes it will solve your problems ;)

npm affected:apps Will tell you which lambdas needs to be rebuild and redeployed

Take a look additionally at Nx DeployIt -> it manages already lambdas too and you can easy deploy them to AWS

So there you could do:

nx affected –target=deploy

And all your lambdas which are affected would be rebuild and deployed for you

Hm thanks for the commentary, - I am trying to figure out of nx maintains a DAG where I can indicate dependencies w/o populating the node_modules with irrelevant requirements - for example, I want an ‘app’ in your lingo to be converted into a zip, and then only the zip to be brought over to another project, but the dependency graph to still be maintained as appropriate.