Add name/index.less to file search path

[zanona]

I believe it would be very beneficial for Less users who want to split their work in modules on different directories to allow Less to search for files named index.less within that directory in case the format can't be found, this would help requiring dependencies in the same fashion other systems allow, like commonJS?

For example, the below would be valid:

@import 'lib/main' /*searches on lib/main.less and lib/main/index.less*/

Perhaps there's already an way to achieve this behaviour? If someone could let me know it would be really appreciated.

Thanks in advance.

[seven-phases-max]

How many Less libraries do you know with their master file named index.less?
I don't like the idea of forcing either predefined file names for the sake of syntactic sugar (5 chars economy for index? Now what if I don't like index and want the master file of my button component to be named button or main or whatever?).

[zanona]

@seven-phases-max I believe it could be just a question of defaults. Analysing its correlation with CommonJS makes it easier to understand:

var foo = require('./foo');
var foo = require('./foo/index');
var foo = require('./foo/index.js');

All the examples above are valid ones, so nothing prevents users to have their main file pointing to something different like require('./foo/bar.js') instead.

So I believe the suggestion might not only serve a purpose to save 5 characters but instead seeing things in a more modular fashion, the stylistic beauty comes as a bonus. Also, the similarity between javascript modules and less files would certainly be a very pleasing way to work with.

Considering the following file structure:

./lib
├── auth
│   ├── index.js
│   └── index.less
├── fonts
│   ├── MuseoSansRounded-300.otf
│   ├── MuseoSansRounded-500.otf
│   ├── MuseoSansRounded-700.otf
│   ├── fontawesome.ttf
│   └── index.less
├── forms
│   ├── index.js
│   └── index.less
├── nav
│   ├── index.js
│   └── index.less
├── scrollmap
│   └── index.js
└── video
    ├── index.js
    └── index.less

Look at how similar javascript and less files get in terms of structure.

main.less

@import './lib/nav';
@import './lib/video';
@import './lib/auth';
…

main.js

var nav   = require('./lib/nav'),
    video = require('./lib/video'),
    auth  = require('./lib/auth');
…

Of course in both cases the index word could appear, but that becomes unnecessary once you start to visualise projects as module-dependant.

Honestly, I would believe that if this same decision was taken in order to adapt this kind of behaviour into other systems, it could mean a positive thing.

[zanona]

@seven-phases-max Also in regards to your question:

How many Less libraries do you know with their master file named index.less?

Replying with another question might be an interesting way to analyse the current situation.

How many Less libraries have you currently required in the following manner: @import ../path/module-name/module-name.less?

So I believe in this case there's a rather unnecessary redundancy in regards directory name and file name. I have seen quite a few libraries doing that. Actually, based on my experience, the great majority. But that's just because currently there's no other intuitive way to do it.
So index.less can be a good option for fixing that I believe.

[seven-phases-max]

This implies the addiction to a particular naming/code-structuring scheme... I know it's pretty much useless to resist to a popular and wide-spread (in a certain realm) pattern, but for those who came from other realms all this may not be so natural. Either way, the answer is probably in "Implement as plugin" (Less itself is not supposed to be a package/module manager like CommonJS or npm or bower or whatever, so I suspect putting this into the core would be an overkill).
So I'll add the corresponding label - preliminary (to be changed if there're other opinions).

[zanona]

That makes sense — Separating it as a plugin.
I will read the documentation on how to implement a plugin and post back here in case I am successful.

Thanks for your help @seven-phases-max.

[seven-phases-max]

To answer:

How many Less libraries have you currently required in the following manner: @import ../path/module-name/module-name.less?

None. I use another code structuring pattern where the component master file is not put into the directory of auxiliary/asset files of that component, so in my realm all these imports look just like:

@import "lib/button"; // ->"lib/button.less" which then refers to whatever files in `lib/button` (or whatever) dir
@import "lib/nav";
@import "lib/etc";

[zanona]

But that makes it impossible to integrate with package managers (bower, npm, etc) where they are downloaded inside their own directories. So for the everyone using those, would certainly be left out.

It certainly works within your system but if you just look around you will see many of the examples mentioned. Lesshat as possibly being one of the most downloaded Less libraries out there.

Installation:

npm i lesshat 
bower i lesshat

Importing:

@import 'node_modules/lesshat/build/lesshat.less';
@import 'bower_components/lesshat/build/lesshat.less';

In this case they have the build directory as well, but the issue with repeating module-names are still in place.

Also, in regards your mention:

(Less itself is not supposed to be a package/module manager like CommonJS or npm or bower or whatever, so I suspect putting this into the core would be an overkill).

CommonJS can certainly be categorised in the same level as Less since it just interprets modules but is not responsible for managing them. So in that case the index use-case was still added either way?

You have mentioned the plugin solution which I would be happy to attempt, but I am not sure if a plugin would have any chance to interact and act on how and where Less reads/searches files from? Would you by any chance have any recommendations?

[zanona]

Just a confirmation I am not alone on this: sass/sass#690

[matthew-dean]

This is a duplicate issue/request. Will find/tag the duplicate when I have a moment, unless someone else can.

[matthew-dean]

Closing as duplicate of #1339.