Lambda file structure

[ro-savage]

I recently encountered the issue around the folder structure that optimize creates and trying to access things on the file system (#32).

I was wondering why it makes that structure at all, rather than your function and files being uploaded directly into the root of each lambda?

Is there a specific reason?

[goncaloneves]

Hi @ro-savage.

Reason of doing that is not break usage of fs in code. This plugin doesn't scrape and change file system paths in the code, so one example is that if you would have the function handler deep into a folder and use fs to fetch a file at runtime in the service folder, you wouldn't be able to do that by having it at the same level.

[thebrianbug]

It's been a long time, but #32 is definitely a wart on an otherwise amazingly pleasant plugin. Is this plugin still maintained?

It would be ideal if static assets could be referenced via require('./relative/path/file.json') as well as import equivalent. I'd rather the file be copied in two places if the concern is to preserve fs access. Needed to rewrite all imports in a large mono-repo is a big letdown. For those who don't want two copies maybe having a new configuration option with the asset copy strategy would be ideal (preserve fs access, preserve relative import access, or both - which would make 2 copies).

Let me know if this might be an acceptable solution!

@goncaloneves

[thebrianbug]

What I'd consider doing is deploying the function code to the root of the lambda, or in other words not nesting code in the _optimize folder for a deployment. I agree with @ro-savage, needing to use a nested temporary folder is quite strange in the deployment and breaks code from not having the same root directory