Optional ~ for modules

[donaldpipowitch]

Why do I need to prepend ~ for modules? I'd rather prepend ./ for relative files. This seems to work great, when I comment this line: var moduleRequest = loaderUtils.urlToRequest(filename, query.root);

@import "module-foo/style.less"; // loads from my modules
@import "./module-bar.less"; // loads relative file

Can we make ~ optional?

[donaldpipowitch]

My problem could actually be solved by supporting Less paths option implemented in this pull request: #75.

[jhnns]

I would like to change that as well... it's counter-intuitive and forces you to write your less files in a way that just webpack is able to understand it.

However, it was @sokra 's decision back then and I don't know if it's wise to change that now with a major version bump. That would probably force a lot of people to refactor their code 😁

[donaldpipowitch]

It would be nice to see this change though, so our Less modules can be loaded with a non-webpack-stack as well.

[jhnns]

I've thought about this today. We could make it optional by first doing a lookup with urlToRequest and then without urlToRequest. Thus we won't break existing code and enable the lookup as "fallback".

However, the problem still remains with url() imports of images, because these are handled by the css-loader. So, the goal "compilation with a non-webpack-stack" is only possible as long as you don't need to reference images in other packages. That's why I would like to have @sokra 's opinion about it if we could deprecate the ~ import.

It's a tough decision because the ~ makes sense if you want to preserve CSS' native way of referencing other resources 😞. However, with modern build tools, people get used to 1. somehow precompile their stuff and 2. distinguish between relative and package (aka node_modules) imports. So this is probably a valid change.

Additionally, we should align this decision with the sass-loader, as it is very similar to the less-loader.

[jhnns]

Concerning your PR #75: I'd first like to have a decision here. Because in case we remove ~ imports, I'd rather not implement the includePath option because there should be only one way to handle your imports.

[donaldpipowitch]

That's fine. I totally understand your concerns and didn't knew that css-loader is responsible for image loading. You're right: this should be addressed in all loaders. For all loaders I'd like to either use relative (./foo) or absolute (/foo) paths and for everything else (foo) try loading via node resolve logic.

[sokra]

CSS and less only know about relative urls, they have no idea what "modules" are... Both less-loader and css-loader are designed to handle existing code well. So url(file) and @import "file" resolve relative by default. Existing libraries are written this way. (i. e. https://github.com/twbs/bootstrap/blob/master/less/bootstrap.less)

So the ~ is a webpack-only escape char to point to modules. It leaves the existing behavior intact and only adds ~ as feature.

The less-loader aligns with the underlying less language. It doesn't change the language it only adds the ~ feature.

So the best way to add modules to the less-loader would be to add module urls to the less language. Maybe something like @import (module) "module-foo/file". This would be compatible to exisiting code.

Trying to resolve both, first normal, than as module, would be a webpack-only extension to the less language and would not be better than ~ (which is also webpack-only). Both make you write code which is webpack-only... :(

Related:

• Support for importing from npm packages: @import (npm) ... less/less.js#1965
• https://github.com/less/less-plugin-npm-import
• add moduleUrl option less/less.js#2615

[jhnns]

Existing libraries are written this way.

Yes, correct. That's why we should not change the semantics. Basically, writing import "foo" should always look at ./foo first – or otherwise we would be incompatible with a lot of libraries.

Trying to resolve both, first normal, than as module, would be a webpack-only extension to the less language and would not be better than ~

I don't think that this would be a webpack-only way. It's basically the same as when using the --include-path option. Unfortunately, this only works for LESS imports, not for url() statements, which are not resolved by LESS.

[donaldpipowitch]

So url(file) and @import "file" resolve relative by default. Existing libraries are written this way. (i. e. https://github.com/twbs/bootstrap/blob/master/less/bootstrap.less)

Yes, but I'd expect that the bower Bootstrap maintainers would maybe accept a pull request to change an import from @import "file" to @import "./file" for explicit relative loading, but I doubt they would add a ~ (if they would load a dependency themselves), if that would mean all their users would have to use webpack.

[jhnns]

With "bower" you mean LESS? 😀

And yes, LESS is actually considering to enable this via option

[donaldpipowitch]

Sorry, I meant "Bootstrap" instead of "Bower", because the example sokra mentioned was Bootstrap :D

[donaldpipowitch]

I'd like to come to a conclusion here. As seen in #79 and #81 more people are bitten by this recently. I'll try to breakdown the current status quo:

• Less resolves files relative by default.
• Less has no built-in module resolving logic, but you can point to module directories like node_modules or bower_components with the paths. (It is also possible to use plugins like this one.)
• PR change context by using paths array #75 adds paths to less-loader, but as @jhnns said, this only works for importing Less files, not url() statements.
• For now less-loader required us to prefix file paths with ~ to use Webpacks module resolving logic. This requires every developer to use Webpack, if the developer wants to use a Less file using this.

My proposal: Try resolving Less files relative by default. If you can't find a relative file use Webpacks module resolving logic to find a corresponding module (just like it would work if you use paths and no Webpack). The same logic will be used for url() statements and other referenced files. No need for ~ and no need for PR #75. If you want to use relative files explicitly you can use ./.

[ritz078]

It will be really nice if we can write code that isn't only for webpack. Currently, the compulsion to use ~ is the reason I can't integrate webpack in my project .

[timmfin]

Surprised no one has yet mentioned omit-tilde-webpack-plugin. While it does not directly solve the problem, it is very related and may help a few folks out (or maybe show some precedent for optional ~... at least for hacking in support for legacy/non-webpack-aware code?).