Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Clarify goals with webpack (in)dependence

See original GitHub issue

In #90, 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).


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?

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:9 (5 by maintainers)

github_iconTop GitHub Comments

gaearoncommented, Jul 23, 2016

Things like require.ensure could be problematic but those tend to be used more sparingly than CSS (which is basically half of the project files). They aren’t as painful to migrate away from as custom syntax extensions to CSS, I think.

If we add more JS tools they aren’t going to fail because of require.ensures. Webpack overloads some semantics here but it’s still a JS function call. It’s easy to codemod away if we ever need to do it. We also think code splitting is a necessary feature and we’d have to support it one way or another anyway (although Webpack 2 APIs for this look nicer and we’d like to switch to them in the future).

CSS Modules is much more involved. If you look around PostCSS repos, you’ll find tens of unsolved issues related to CSS Modules support, for example. I’m not saying we plan to use PostCSS more extensively, but we don’t want this to lock ourselves out of this, or to have to figure out how to fix many issues caused by overloading of CSS semantics with custom syntax.

Ultimately our current usage of CSS files is a compromise. We would like to eventually move to a way to represent styles in JS instead. This is a longer term goal and it will take a while before we have something we can recommend to people. But we think this is a better solution to encapsulating styles than a custom syntax extension to CSS.

Since we can’t reach this goal soon, we want to at least leave the door open for it. It seems to me that, the closer our files to vanilla CSS, the easier it will be to automatically codemod them to JS someday if we decide to proceed with moving into that direction. Custom extensions make this harder in my opinion but maybe I’m wrong.

Then why do we even use the Webpack way of importing CSS into components? Again, practical reasons:

  1. We want to have at least some knowledge about which CSS files are associated with which components in case we want to codemod CSS usage later.
  2. This automatically integrates those files into Webpack build system so it puts right content hashes on output files. This tool has an explicit goal of being suitable for production, and we can’t ask users to run additional “revving” tasks. This nicely sidesteps the problem.
  3. This gives us hot reloading of CSS in development which is super convenient.

To sum up:

  1. We prefer conventions to custom syntax
  2. We don’t know which tools we will support in the future so we don’t want to introduce more potential incompatibilities
  3. We think the real solution to encapsulation is using JavaScript primitives (modules), not custom syntax in CSS
  4. We want to use patterns practical in production apps so our users don’t need to worry about hashes and stuff
  5. We are okay with suboptimal patterns that are relatively easy to codemod away from

I understand if you disagree with some of these points. Like everybody, we are exploring this space, and we need to make some decisions. We might eventually change our minds but for now we decided we care about specifying JS <-> asset dependencies but want assets to stay as vanilla as possible. I hope this helps.

jquensecommented, Jul 27, 2016

Until it does, we don’t want to artificially “bless” the existing non-vanilla-CSS options by supporting them (rather than their alternatives) here.

This seems like saying “Because we haven’t yet reinvented CSS in React we are going to ignore the last 5 years of best practices, improvements and common choices made by most web developers”. Not to harp on a point but this is exactly the sort of thing folks from outside the React community face palm and shake their head about, a seemingly tone deafness to how most productive web development works outside the bubble of bleeding edge React innovations.

If React isn’t going to have its own special solution then it should at least support some of the things the majority of modern web developers use now and not tell them to do something actively bad like use “plain css”. If anything we should at least look at how successful versions of these tools in other communities work and copy them. Both emberCli and AngualrCli support some amount of config, and easy options for handling CSS (and others) and that has not lead ppl to “fatigue”. Hopefully, there is probably a spot between “nothing” and “write your own babel and postCSS plugins for everything you need”

Read more comments on GitHub >

github_iconTop Results From Across the Web

Dependency Management - webpack
It allows you to pass in a directory to search, a flag indicating whether subdirectories should be searched too, and a regular expression...
Read more >
Keep webpack Fast: A Field Guide for Better Build Performance
Keep webpack Fast: A Field Guide for Better Build Performance ... webpack is a brilliant tool for bundling frontend assets. When things start...
Read more >
An in-depth perspective on webpack's bundling process
Simply put, a dependency is just a preliminary to an actual module instance. For instance, even the entry object's items are dependencies in ......
Read more >
An in-depth guide to performance optimization with webpack
Common code splitting aims to combine shared code into separate bundles to achieve smaller bundle sizes and more efficient caching. It's similar ...
Read more >
How We Reduced Startup Time by 80% With Webpack
1. Install required dependencies · 2. Create and export your config file · 3. Add config to instruct webpack where to find your...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found