vercelPreset changes build directory structure, breaking start script from remix docs about remix

[lifeiscontent]

personally a few reasons:

1. check output of prod build to see if it looks how I'd expect / debug something that only shows up in prod.
2. making sure my understanding around how process.env.NODE_ENV works across development/production environments with vite. (e.g. its the only variable that I know of that is exposed across client/server)
3. making sure useEffect works as expected (runs once in prod vs twice in dev because of StrictMode)
4. making sure some CSP policy is applied correctly for prod.
5. making sure other analytics scripts are being applied properly.

[justin-hackin]

Why would you need to run a start script as opposed to running the remix vite:dev dev server?

In order to test out the build locally because of some issues I'm only getting in production

[TooTallNate]

Why would you need to run a start script as opposed to running the remix vite:dev dev server?

[TooTallNate]

Fair enough. So you would need to adjust the file path in your "start" script to match the path which gets created with the plugin. Or you could disable the plugin for your local debugging / verification session.

I'll close this though since "changes build directory structure" is by design, and a result of the plugin's serverBundles option usage.

[justin-hackin]

Fair enough. So you would need to adjust the file path in your "start" script to match the path which gets created with the plugin. Or you could disable the plugin for your local debugging / verification session.

I'll close this though since "changes build directory structure" is by design, and a result of the plugin's serverBundles option usage.

Okay, thanks for helping me understand what's going on under the hood. I noticed the nodejs-ID folder is consistent. My repo is private right now and I was concerned I might be exposing some kind of secret by having the directory name in my scripts when it goes public.

[TooTallNate]

Ya, the ID is generated based on the export const config object's configuration (if any) in your routes, so it will be consistent with common route configurations.