Server Side Rendering: Mark files as 'SSR-ready', and warn if they're modified

[ehg]

In order to remove shared, and provide visibility on which modules in the codebase are compatible with SSR, we should provide some way of marking files with some form of pragma, e.g. /* @ssr-ready */.

The reason for the pragma, instead of a plain old comment, is so we can programatically ensure that modifications to these files don't violate any SSR constraints, and provide feedback if they do.

The pragma approach could also be extended into other scenarios, such as /* @react-native-ready */.

There are a couple of ways I can think of to do this:

• Use a webpack loader, which will scan a file's dependencies, and make sure they're all marked as SSR-ready. The challenges with this approach are that it needs to be fast, and will need to take into account npm modules. The main benefit is that we can exit the make run process, or provide warnings in the browser. We could also specify any modules we'd like to 'stub' in the pragma for SSR.
• Use an eslint plugin to enforce some rules, or a separate script, which would be run on commit. This would take the burden off the build process, but we may lose some flexibility without access to the dependency graph. It could also be less visible, as certain git clients or IDEs may not show the pre-commit messages.

[mtias]

Thanks for looking into this. I think it's a big benefit to have this information explicitly in the file instead of implicitly in the directory structure.

[gziolo]

Are we going to move any folders like /lib/ and /component/ to the root level, or we rather aim to import client code marked as @ssr-ready in server folder?

[mtias]

@gziolo the plan is to rename client to app and keep the internal organisation it has now.

[gziolo]

I like it very much 👍

[nb]

👍

This will be very useful in the long-term and seems on the easy side to implement.