fix: clearing the .amplify/generated/env/ before synthesis #2031
Conversation
🦋 Changeset detectedLatest commit: 2a2b188 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| const pathToDelete = `${process.cwd()}/.amplify/generated/env/`; | ||
|
|
||
| // Clear any existing files and subdirectories in the directory | ||
| fs.rmSync(pathToDelete, { recursive: true, force: true }); |
There was a problem hiding this comment.
Two things.
- The path should be concatenated with
path.joinapi . This means we also have this problem here - could you include fix for this part in the PR ? - This is a function specific code. The logic should somehow go to
backend-function. Possible solutions for that:- Have this as static initializer somewhere, perhaps
FunctionEnvironmentTypeGenerator. - Expose lifycycle hooks from ConstructFactory. For example
ConstructFactory.beforeAll(having in mind that we might addConstructFactory.beforeEachsome time in the future).
- Have this as static initializer somewhere, perhaps
@rtpascual @Amplifiyer wdyt ?
There was a problem hiding this comment.
I was initially thinking 2i but we would have to be careful this won't delete the generated directory during synth of multiple functions right?
I'm wondering if we will ever see more use cases similar to this in other packages to warrant 2ii.
There was a problem hiding this comment.
won't delete the generated directory during synth of multiple functions right?
If we make it run once in static context, before any FunctionEnvironmentTypeGenerator ctor runs then in theory this should work. But won't be super testable.
2ii seems like a proper way to hook this up into framework and control the control flow explicitly.
Would we need this else where, hard to say, but we could ride on 2i until second candidate appears.
There was a problem hiding this comment.
If we make it run once in static context, before any FunctionEnvironmentTypeGenerator ctor runs then in theory this should work. But won't be super testable.
Oh I see what you mean now. Yeah I can only think a good way to test this is in e2e, for example we create app with function -> run sandbox-> update function name -> check for old generated file after hotswap.
I agree it may be too much right now to do 2ii, 2i will work for this.
Problem
The
.amplify/generated/env/directory is not cleared before deployments, causing outdated/renamed environment files to remain. This can lead to confusion and potential errors when the function's handler code does not match the current environment settings.Changes
backend_factory.tsto clear the.amplify/generated/env/directory at the start of each deployment.Validation
Checklist
run-e2elabel set.