less loader paths option doesn't work

[zhenzong]

In my project, there is a '/lib/css' folder. When I write less code in 'src' folder, I prefer

@import 'some.less'

to

@import '../../../lib/css/some.less'

so, In my webpack.conf.js

{
            test: /\.less$/,
            loader: 'style!css!less?{"paths": ["./lib/css"]}'
 }

according to less option usage (see http://lesscss.org/usage/#command-line-usage-options) and README.md (https://github.com/webpack/less-loader#less-options), but it seems doesn't work.

PS:   loader: 'style!css!less?paths=["./lib/css"]}' also doesn't work

Is anything wrong ? Please help me out.

I would like to chime in that having to pass these kinds of options as query variables creates some nasty syntax. It would be nice to be able to set things like this using loader options. For example, setting search paths for the Sass loader is easy:

'sassLoader': {
    'includePaths': [
      path.join( __dirname, 'src/ui/styles' )
    ]
  }

[zhenzong]

@chrismbeckett Using query variables to pass options is standard way. see webpack using loaders document. Webpack also supports configuration object. But it doesn't work no matter how I pass paths option. There is a pr ( #75) for solving this problem. but hasn't merged yet.

[oller]

So to clarify, there's currently no way to pass the includePath option to LESS?

Have tried various combinations:

{
    test: /\.less$/,
    loader: "style!css!less?includePath=" + path.resolve(__dirname, "../core/app/styles")
},

{
    test: /\.less$/,
    loader: "style!css!less?{'includePath': [path.resolve(__dirname, "../core/app/styles")]}"
},

{
    test: /\.less$/,
    loader: "style!css!less?{'paths': [path.resolve(__dirname, "../core/app/styles")}"
},

[wspringer]

I can't get it to work either.

[viridia]

Same here

[zhenzong]

I use resolve.alias webpack configuration(see http://webpack.github.io/docs/configuration.html#resolve-alias) to solve this problem.

In webpack.config.js:

var PATH_MAP = (function(){
      // read lib path and make PATH_MAP object
}());
module.exports = {
    // other configuration
    resolve: {
        alias: PATH_MAP,
    }
}

for example, PATH_MAP is

{
    // less
    'swiper.less': '../../path/to/swiper.less',
    // js
    'swiper': '../../path/to/swiper.js'
}

then I can use

@import "~swiper.less";

to import swiper.less, and use

import Swiper from 'swiper';

to require swiper with es2015 syntax.

Thank you all.

[viridia]

The problem that I have is with the @import statements within the .less files themselves - I'm trying to use the semantic-ui-less package, which contains import statements of the form @import "../../theme.config" (the idea is that you put a theme.config in your own project which overrides the default theme). I can't modify the import statements to include the '~', and I can't use resolve.alias because (AFAICT) the @import paths aren't processed through the webpack resolver (which makes sense actually, as these files are part of the less build).

[Jastrzebowski]

Same for me. Seams like includePaths doesn't change anything, standard CLI works great:

lessc --include-path=my/path file.less

but loader throws an error… 😕

{
    test: /\.less$/,
    loader: 'style!css!less?includePaths=my/path'
}

[zhenzong]

@viridia Can you use the semantic-ui-less package's source code? I think maybe you can copy the source code into you project, then modify the source code. But it's a ugly way. Or there is another way. Create a new project which contains your less code and dependency library, then write a shell script, use lessc to compile less, then just move the result file to your original project.
: )

[zhenzong]

@Jastrzebowski Maybe you can try to use resolve.alias, and I use it to solve my problem.

[AndyOGo]

I have encountered the same issue.
I really favour a standard solution supporting the less build in --include-path option.

This embraces portability, the tilde hack makes things really a burden.

[zhenzong]

I don't like tilde hack too,

[AndyOGo]

@zhenzong
Agree.
Actually i found this other related issue #74.
It's a exploded discussion since January, though there is already a PR... :(