Rewrites with conflicting paths

This is continued from the discussion in https://github.com/serverless-nextjs/serverless-next.js/issues/646

Reproduction here: https://github.com/patricktyndall/sls-next-bug-reproduction

Describe the bug

When rewrite paths conflict with /public or static routes in /pages, things start breaking.

Actual behavior

/dynamic-1, /login, and /my-test-asset.txt break

Expected behavior

/dynamic-1, /login, and /my-test-asset.txt don’t break

Steps to reproduce

Deploy using serverless

Versions

• OS/Environment: MacOs
• @sls-next/serverless-component version: @sls-next/serverless-component@1.18.0-alpha.13
• Next.js version: 9.5.5

Additional context

This is important because it prevents existing next.js apps from using this component, as it breaks compatibility.

I added comments in next.config.js on what happens when you change the rewrites.

[dphang]

Yep, I do note that - just was trying to clarify how it’s implemented right now - it just takes the first matching rewrite and tries to rewrite it (it doesn’t know about no-ops, doesn’t know about existing non-dynamic pages or static/public files).

I did test the repro with the dev server and confirm your findings. Even with or without the no-op rewrite, it looks like next also doesn’t rewrite non-dynamic routes such as /login (so /:path* to /content/:path is not going to rewrite /login, as /login has priority).

However, for dynamic routes like /content/dynamic-1, the no-op rewrite seems to prevent those from being rewritten (your destination is /content/:path, so I changed this to something else to test this - either another internal route or external route).

I think this has helped cleared things out. So looks like there are two things to fix:

1. Public/static files and non-dynamic pages should always be prioritized over rewrites, i.e they will never be rewritten. This is per Next.js documentation.
2. No-op rewrite should be respected to try to first match to any existing route (including non-dynamic and dynamic routes), before doing any further rewrite. Documentation in Next.js seems to agree on this, although it’s a bit less clear as no-op rewrites are only mentioned in the context of external rewrites, but it applies to all kinds of rewrites.

[dphang]

Fixed and released in latest alpha.