Why does importing LESS (.less) files fail silently and what do I do if I need to use LESS and want to use CRA?
See original GitHub issueThe 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.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (7 by maintainers)
Top GitHub 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?
I think what would be tremendously useful is for webpack to include
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.)
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