Clarify goals with webpack (in)dependence

Created by: modernserf

In #90 (closed), regarding support for webpack's native support for css modules, @gaearon says:

We might want to migrate away from webpack in the future. We’d need to make our CSS files are as vanilla CSS as possible (aside from minor stuff like relative dependency paths).

and:

Having to back out of infrastructure changes (e.g. super fast new bundler) because people relied on webpack in ways like this would be super sad.

However, there are still a ton of other webpack-isms. Some, like require.ensure for code splitting, will probably be banned now that I've drawn your attention to them. But others, like import logo from './logo.svg' or import './App.css' are not only permitted but are part of the boilerplate.

I understand that the purpose of this config is to completely abstract Babel/ESLint/webpack configuration from users, and allow for tooling to change mostly independently from app code. I also understand that some webpack-isms, like image and non-modular CSS loading, are extremely useful for React development.

But CSS modules and dynamic loading/code splitting are also very useful; a decision has been/will be made made that their use does not outweigh the costs. Meanwhile, import logo from './logo.svg' isn't strictly necessary -- images and CSS could be in a static/ directory that gets served by the dev server and bundled in the build -- but this project has chosen the more ergonomic approach, even though it couples the project to webpack-specific implementation.

Obviously you have to find a sweet spot between no webpack-isms (if you do that, why even bother?) and all webpack-isms (because that impedes you from using any other tools, and even webpack might drop support for these). So how do you do it? What are your heuristics?