Serverless-next.js: Next.js 9.1 public directory support

[jayarnielsen]

Describe the bug
As of next.js 9.1, the static directory should be placed inside of the public directory. https://nextjs.org/blog/next-9-1#public-directory-support

With the current serverless component, files in the public/static/* folder are unreachable because of the cloudfront rule for static/*.

To Reproduce
Steps to reproduce the behavior:

1. place static assets in public/static
2. deploy
3. try to access static asset at domain.tld/static

Expected behavior
Static asset resolves.

[Enalmada]

This would be good to prioritize as old Next users will be encouraged to migrate as console says The static directory has been deprecated in favor of the public directory. https://err.sh/zeit/next.js/static-dir-deprecated and new users to Next will put everything in the public/static directory. Moving things to 'public/static' will work locally but not work using serverless-next.

[PrimeObjects]

Not sure whether it is the same issue, I have images in /public/images folder, it works fine when it runs locally. After deploying to AWS, I can see a public folder in my S3, However /images/file.mp4 does not work.

[skycremaschinin]

opened PR #234 to solve this issue

[romainquellec]

Is it closed as the PR is accepted ?
Nevermind :

ok, got it.
i'll do some tests and open a new pr.

Any news about this issue ?

[mikestopcontinues]

What's the status on this?

[aldrinc]

For folks landing here wondering about why images don't show up when placed in sub folders. I found that having any assets in sub folders under /public does not work when deployed.

Unfortunately as a workaround I had to move out all my assets from sub folders like /public/images directly into /public so they could be accessed. If anyone knows a different workaround I'm all ears.

Additionally, new assets that are added to public folder don't automatically get the correct permissions when deployed. I have to manually update them as public in S3 so the assets (e.g. images) are visible in my application.

[danielcondemarin]

I have tested on the latest version of the project and is working as expected.

There is only one caveat, if you have both static/ and public/static folders, only resources in static/ will be found. I intend to completely remove support for static/ in the next major version bump to avoid confusion.

Could folks test and feedback using the latest version?

[danielcondemarin]

Closing this as it should be working as expected

[keisukekomeda]

I think the case "1" shown below is the only acceptable code.
I am wondering whether all the request for static image assets kick the lambda@Edge, or cloud front cache allows us to get image file without kick lambda@Edge?

1. Put image files in public dir, and jsx is like <img src="image.png">.
   In this case, both local environment and deployed environment work.

2. Put image files in public/static dir, and jsx is like <img src="public/static/image.png" />.
   In this case, deployed environment works, but local environment doesn't work.

3. Put image files in public/static dir, and jsx is like <img src="static/image.png" />.
   In this case, local environment works, but deployed environment doesn't work.

[stan-sack]

I don't think that public/static/ works. To actually test this you need to go to your bucket and delete the residual static folder which will be left from previous deployments. I could also see that all the files were correctly uploaded to the public/static/ folder however I'm getting a 403 from cloudfront. I invalidated my cloudfront cache just to be sure that wasnt the issue and I'm still getting a 403. This is using latest master.

Moving the files back to /static fixes the issue.

[malimccalla]

Im having an issue with this too. Locally files in public/img are being loaded but after building the project and dpeloying they are not working. Will work on a reproduction and open a new issue

[joebanks10]

I noticed that removing the cloudfront behavior rule for the static/* path pattern fixes the issue. Is there a way to prevent this rule to be written @danielcondemarin ?

[danielcondemarin]

I noticed that removing the cloudfront behavior rule for the static/* path pattern fixes the issue. Is there a way to prevent this rule to be written @danielcondemarin ?

There isn't a way right now to prevent it from being added. I am tempted to remove it completely but that would be a breaking change. I think is worth looking into how the Next.js server does this and do the same. Maybe if the static folder is present add the static/* cache behaviour otherwise don't.

[joebanks10]

That sounds good to me! Or a config option works too. For an immediate workaround, we're migrating static files to a new folder (e.g.public/assets) to avoid the conflict. Thanks!