Create-react-app: Why does importing LESS (.less) files fail silently and what do I do if I need to use LESS and want to use CRA?

Created on 19 Dec 2016  Â·  10Comments  Â·  Source: facebook/create-react-app

The documentation clearly states that LESS or Sass are not supported. In Issue #78 I read that this seems to be a touchy issue.

If I do this in index.js:

import './test.less';

and create test.less with the following content:

Should I be seeing a compile error?

I am not, in fact, seeing a compile error, or any error, for that matter. The application starts, just without the LESS code in test.less. I consider this a defect of some kind.

I was affected by this issue when trying to port a medium-size React.JS application (about 1 year old), which used LESS, to create-react-app. Our motivation for attempting this were that we never could get HMR to work in the old app, making front-end development tediously slow (in CRA, it mostly works), and that we want to use the rest of CRA's webpack config, including its Babel and eslint presets, particularly with an eye towards upgrading to Webpack 2.0. In a 1 year old application, several packages are multiple semantic versions behind (react, react-bootstrap, redux, redux-forms, ... you name it), and just waiting for compile errors without incremental compilation would is aggravating.

If create-react-app is not the tool for that use case, what is? Maybe we need 'maintain-react-app' project, or a react-cli project. Irony: Googling for react-cli finds this project.

up for grabs! documentation

Most helpful comment

Any files with unknown extensions are treated as wanting to add a file to the build output (with hashing). This is useful because we don't need to add file to several whitelists once somebody needs an obscure extension.

Less compilation is not supported out of the box. However you can use its CLI to compile Less files to CSS, and import the resulting CSS. Does this work for your use case?

All 10 comments

Any files with unknown extensions are treated as wanting to add a file to the build output (with hashing). This is useful because we don't need to add file to several whitelists once somebody needs an obscure extension.

Less compilation is not supported out of the box. However you can use its CLI to compile Less files to CSS, and import the resulting CSS. Does this work for your use case?

Perhaps for the benefit of others may I share what I found to elaborate on @gaearon 's answer. Please correct if I'm wrong.

Trying to understand what is meant by "add a file to the build output," I performed some experiments. Just saying import 'test.less' does absolutely nothing. However, if I use the result of the import, as in import R from 'test.less'; console.dir(R) R takes on a string value that embeds a data: URL with, presumably, the content of the file. Quick skim of the CRA documentation does not find any paragraph that addresses unknown file extensions.

From an SO answer I am able to infer that this is likely the result of a module call url-loader. In trying to track down documentation on this module I found its github homepage, which however only says: "The url loader works like the file loader...", then refers to the webpack documentation on loaders which discusses neither file-loader nor url-loader in any detail. Searching for file-loader in the "Search the docs" box gives one hit on a page Long Term Caching which does not talk about file-loader, either. Finally, a Google search on "file-loader webpack" eventually finds its github.com homepage. What is not clear if this loader is part of webpack or an independent module.

If I understand it correctly, to be able to use less, I will need to either add a corresponding rule to the webpack config (which I can't change while staying unejected from CRA), or run it on the command line to produce CSS, which in turn will mean no automatic recompilation when I make changes.
This is a bit unsatisfying.

It seems configuration of, in particular, webpack, has gotten so complicated that the need for a "convention over configuration" scaffolding like CRA arose, but then it is difficult for people to live within its confines given the judgement calls it makes on what is and isn't part of essential infrastructure.

The next issue I'm facing is that our project has some custom eslint rules (like 2-space indent, requiring semicolons), which according to my reading of issues #808 and #734 will stay outside create-react-app. So we need CRA because we're scared of touching webpack otherwise, but then we'll have to use bandaids and work-arounds to perform even mild configuration. Not a great situation. The answer is likely for webpack's complexity to come down so that when a problem occurs, we don't have to take apart the entire compiler like we did in issue #1023.

Quick skim of the CRA documentation does not find any paragraph that addresses unknown file extensions.

If you could submit a PR it would be great! This was mentioned in the changelog but indeed we didn't document it.

From an SO answer I am able to infer that this is likely the result of a module call url-loader.

Sorry, I didn't mean that you should search for Webpack docs to understand this. My point was that if you import a module with any non-JS/CSS extension (usually people use this for images or videos), it will get added to the build output, and the result of the import will be the URL of this file. If the file is small enough it will get inlined (you'll still get a URL though). This is useful for small images.

We should probably only whitelist inlining for specific extensions (namely, images). It wouldn't make sense to attempt to inline, e.g., a PDF file. So I'll reopen this issue to revisit that decision.

If I understand it correctly, to be able to use less, I will need to either add a corresponding rule to the webpack config (which I can't change while staying unejected from CRA), or run it on the command line to produce CSS, which in turn will mean no automatic recompilation when I make changes.

Why not run a command line watcher? If I go to Less docs and search for "watcher" on the page, I find a link to a project called autoless that watches Less files. Or you could use Gulp with something like gulp-less for the same effect.

then it is difficult for people to live within its confines given the judgement calls it makes on what is and isn't part of essential infrastructure.

That’s true, it’s a tough balance. On the other hand I think it’s important that we enforce some of these limitations to make ecosystem more bearable. For example it’s frustrating that some libraries force users to change Webpack configurations. This leads to accumulated config cruft over time. Since those libraries don’t work in CRA, their authors are now compelled to provide simpler ways to integrate and “play well”. I think it’s going to be a net win in the longer term.

So we need CRA because we're scared of touching webpack otherwise, but then we'll have to use bandaids and work-arounds to perform even mild configuration. Not a great situation.

You can add ESLint to your project just like you normally do, and specify your own config. CRA won’t use that config itself, but you are free to add your own task that runs the linter. And at some point we might revisit this (there is an issue).

The answer is likely for webpack's complexity to come down so that when a problem occurs, we don't have to take apart the entire compiler like we did in issue #1023.

Yea. CRA is “bundler on a diet”. It’s a bit more radical than most solutions but I think it helps steer the ecosystem in right direction.

Reopening because we need to document what happens when you import unknown extensions, and probably add a whitelist specifically for url-loader.

I think what would be tremendously useful is for webpack to include

  1. a self-check mode in which is checks its configuration and each included loader/plugin/whatever checks its configuration parameters and reports briefly its purpose. Every other (successful) configurable system has that (nginx -t, httpd -t, etc.)

  2. a verbose mode in which loaders/plug-in etc. report what they do as they do it. Again, every successful compiler/translator in wide use has that (-verbose, usually). Along with a --save-temps. Webpack is the most heavily modular/extensible system I've seen in a long time; its current contract of loaders just being functions that do whatever and access whatever configuration simply does not scale in my opinion.

With such support, people wouldn't need to reverse-engineer and would need to ask fewer questions about just what this thing does with their configuration (or with a configuration provided by an intermediate layer as is CRA).

Please vote for Documentation in webpack

cc @thelarkinn

Anyone working on this? Might take a crack at the whitelisting.

You might also be interested in the alternative of using less via the react-scripts fork [custom-react-scripts](https://github.com/kitze/create-react-app

I'm going to punt this to 0.10.0 since it will land https://github.com/facebookincubator/create-react-app/pull/1305, which is changing the behavior anyway.

I hope this is fine, feel free to re-tag as 0.9.1 if you feel strongly about intermediate documentation.

1305 added documentation detailing this behavior and now results in a URL, not file contents. This will be released in 0.10.0.

Sorry for the confusion!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

alleroux picture alleroux  Â·  3Comments

adrice727 picture adrice727  Â·  3Comments

DaveLindberg picture DaveLindberg  Â·  3Comments

oltsa picture oltsa  Â·  3Comments

xgqfrms-GitHub picture xgqfrms-GitHub  Â·  3Comments