chore: rename NETLIFY_NEXT_PLUGIN_SKIP env var

[orinokai]

The Next Runtime env var NETLIFY_NEXT_PLUGIN_SKIP should be renamed to NETLIFY_NEXT_MANUAL_EXPORT to better signify the fact that the user is doing a manual export and opting into something, rather than opting out.

The runtime should remain backwards compatible with the existing var so it would be good to use a helper to implement this functionality along with general env var checking.

[shaungcheng-asana]

I understand if next static export is the only purpose of this env var then it makes sense to abstract it to like what @orinokai mentioned NETLIFY_NEXT_MANUAL_EXPORT, but I want to bring up that our team has another use case where we use NETLIFY_NEXT_PLUGIN_SKIP to literally disable nextjs runtime, as we have 2 netlify projects sharing the same netlify.toml[1], but one doesn't need @netlify/plugin-nextjs and will break in a nextjs runtime. In this case NETLIFY_NEXT_PLUGIN_SKIP makes more sense to us.

[1] Why we are sharing the same netlify.toml for two projects is a different topic I guess but I can share more about the reason if anyone is interested (and potentially seek feasible alternative)!

[orinokai]

Hi @shaungcheng-asana, thanks for your feedback. I'd love to know your reasons for using the same toml file for 2 projects. Also, can I confirm that the reason the 2nd project breaks with the Runtime is because it is not a Next.js project?

[Designer023]

I understand if next static export is the only purpose of this env var then it makes sense to abstract it to like what @orinokai mentioned NETLIFY_NEXT_MANUAL_EXPORT, but I want to bring up that our team has another use case where we use NETLIFY_NEXT_PLUGIN_SKIP to literally disable nextjs runtime, as we have 2 netlify projects sharing the same netlify.toml[1], but one doesn't need @netlify/plugin-nextjs and will break in a nextjs runtime. In this case NETLIFY_NEXT_PLUGIN_SKIP makes more sense to us.

[1] Why we are sharing the same netlify.toml for two projects is a different topic I guess but I can share more about the reason if anyone is interested (and potentially seek feasible alternative)!

We're also using the NETLIFY_NEXT_PLUGIN_SKIP to disable the plugin in a multiple site project where some sites are not on the next runtime. Ideally this would remain a feature and the NETLIFY_NEXT_MANUAL_EXPORT can be a separate flag

[ascorbic]

I'm going to close this, because there are clearly several other scenarios where you'd want to disable the plugin, so renaming the var would be confusing.