Should (payload) be considered Sacred?

[tyteen4a03]

The latest breaking change and the directory structure people come up with (e.g. https://discord.com/channels/967097582721572934/967097582721572937/1277561801709719623) makes me think: Should Payload demand the (payload) folder be left alone by the users?

Allowing users to modify the folder means extra debugging headaches (as we can't guarantee the files have not been tampered with) and makes breaking changes like what just happened in Beta 79 harder to run than necessary.

If we say (payload) is off limits, then provide tools to re-generate the folder on demand (which also applies if the route to /admin changes, then the script would change the admin folder automatically), then we would have more flexibility in updating the folder as breaking changes like in beta.79 would be reduced to "Re-run npm generate:payloadFolder for most people.

[wkentdag]

noob v2 user here - I assumed this was how things already worked in v3! So, +1 for adopting this convention / gen script.

I noticed a lot of this code comment when I first poked around the v3 demo: THIS FILE WAS GENERATED AUTOMATICALLY BY PAYLOAD. DO NOT MODIFY IT BECAUSE IT COULD BE REWRITTEN AT ANY TIME. However, it looks like folks have since modified files with that warning, so some clarity on best practices here might be helpful.

I guess this is a new concern with v3, since the routing logic that used to be encapsulated within payload.init now needs to be written to the filesystem and checked into git. So, having a first-class script to (re)generate that boilerplate makes a lot of sense and would help minimize surface area for a new set of config errors like the one OP linked. payload generate:[types|graphQLSchema|routes]...?

[wkentdag]

starting to pay more attention to this as v3 nears release, this kind of thing is confusing to me:

the migration instructions are to manually modify a file that starts with "DO NOT MODIFY" 🤔 Is the idea that you won't have to ever modify these files once v3 is stable? and any future update to the (payload) dir will be a breaking release?

[tsemachh]

Totally agree ,
also if someone started with beta10 and now is in beta90 ,
we needed to regenerate empty payload app with beta90 and merge changes to beta10 based code.
It's not a big work , but not always we are aware of those changes.
I am saying always generate if possible , this will save us a lot of issues ,
as we say in the army those instructions were written in blood.
In our case we added to pnpm dev the following:
"dev": "pnpm generate:types && pnpm generate:importmap && cross-env NODE_OPTIONS=\"--inspect --no-deprecation\" next dev",
There can be default generation so we can stay in track always.

[linobino1]

It would also be nice, if we could gitignore the app/(payload)/admin/importMap.js and generate it on the fly. But right now, payload generate:importmap will not work if the file doesn't exist.

[xHomu]

A lot of what we do in config atm are things that theoretically can be done by fiddling the (payload) folder.

Support. The Payload Team should make a judgement call whether (payload) should be off-limits, or offload a lot of the config complexity to (payload) and assume people would mess with it like any other next app route.

[linobino1]

Maybe a pattern like Remix's reveal could be used: The default (payload) directory is implicit, but if you want to customize it, you can call payload reveal to generate the actual files.

[wkentdag]

this would be an elegant solution but not sure if it would work in this case since the Next router is so explicitly tied to the filesystem.