feature: _index.less

[jonschlinkert]

Syntax can be different, it's the concept that is important, originally mentioned by @lukeapage here:#1181 (comment). This isn't my concept, @lukeapage referenced the Stylus implementation, described here: http://learnboost.github.io/stylus/docs/import.html:

The idea is that a folder can contain a special "index" file, which references "sub-components", mixin libs, or feature-subsets related to that library. It might be useful to think of this as having the ability to define dependencies.

./tablet
  |-- index.less
  |-- vendor.less
  |-- buttons.less
  |-- images.less

[matthew-dean]

Is there a way to do this that doesn't kill browser support? The examples seem to reference just a directory name.

[jonschlinkert]

Is browser support necessary for all features?

[matthew-dean]

@jonschlinkert I don't know. It's a good question. I know there are some features already which wouldn't work in-browser, like the data-uri function (I think), but it would be better to decide that. I know that contributed to the debate about continuing browser support.

If some functions don't run in browser mode, it's possible that's okay, but I think we'll need to have a chart on the website that covers which things you can do in which environment.

At the moment, however, because we say that the browser is at least a legitimate testing environment, that would SEEM to imply that all LESS features will work. So it's definitely a choice point of direction.

[jonschlinkert]

@MatthewDL it was a rhetorical question. Based on our discussions and current roadmap, the answer would be no. The plan is to split out the browser code to a separate project in 2.0.0 so that it is maintained specifically for that purpose. I think we'll probably end up organizing the feature requests and issues into the repos where they belong and then judge them on the basis of their intent.

So I'm confused by the chart comment, I think the repo and docs for the browser code should be setup to address that when the transition takes effect.

[matthew-dean]

Well, yes and no. I think part of our separation should be the file I/O, which, I realized, currently exists. So, there would be a separate "node" implementation of the parser which would hand off files when the parser asks for them, which is kind of what happens right now, as is the case with the browser.

File globbing just makes that more complicated, but it occurs to me that the "client-side" implementation of LESS could include a PHP-based file handler for situations like this.

It's probably we're both making assumptions about what that 2.0 roadmap looks like or what the implications are, so it would be good to hash out some documentation behind it.

[matthew-dean]

Also, I don't know the meaning of a "rhetorical question". ;-)

[jonschlinkert]

Really, I'm just thinking that globbing is pretty awesome and it would be cool to see it in Less. But it's not at the top of my list I guess

Sent from my iPhone

On May 23, 2013, at 2:20 PM, Matthew Dean [email protected] wrote:

Well, yes and no. I think part of our separation should be the file I/O, which, I realized, currently exists. So, there would be a separate "node" implementation of the parser which would hand off files when the parser asks for them, which is kind of what happens right now, as is the case with the browser.

File globbing just makes that more complicated, but it occurs to me that the "client-side" implementation of LESS could include a PHP-based file handler for situations like this.

It's probably we're both making assumptions about what that 2.0 roadmap looks like or what the implications are, so it would be good to hash out some documentation behind it.

—
Reply to this email directly or view it on GitHub.

[lukeapage]

@jonschlinkert I don't know. It's a good question. I know there are some features already which wouldn't work in-browser, like the data-uri function (I think), but it would be better to decide that. I know that contributed to the debate about continuing browser support.

it works, it just doesn't do the same thing.. it falls back to being a normal url rather than embedding

I have no problem with things that only work in node.. we want to encourage that and if you use that feature it is usually obvious it won't work in browser?

[jonschlinkert]

I have no problem with things that only work in node.. we want to encourage that and if you use that feature it is usually obvious it won't work in browser?

Agreed, this pretty much summarized my view as well.

[matthew-dean]

I'm on board now as well. I think when LESS migrates to a cleaner separation between parser and implementations, there's an opportunity to have browser support for these features, in fact. I'm envisioning a JavaScript parser in the front end, with a PHP handler for server-side tasks such as this. The parser could hand off tasks like data-uri conversion and directory globbing to server-side scripts.

In fact......

If you kept all parsing logic in JavaScript, paired with a server-side script, you could very very easily support PHP / .NET implementations by then passing off the finished result back to the server, which would then cache the result for you for subsequent requests (if you have file-write permissions). You could then very easily have a "production-level" library that runs in-browser.

Anyway, that's a bit of a tangent. It's just to say that this part of the parser wouldn't work "in Node". It would just work with the Node implementation (or any other) for however they want to handle and return url requests. Either they somehow return the base64 result, or they return the same url reference, but either way, the LESS parser API should be agnostic about things like this that involve file references.

[lukeapage]

Merge this with #1181 and close it?

[matthew-dean]

Merge this with #1181 and close it?

As far as merging, it still seems like a separate feature, no? One is for grabbing all files present, and one is to support shorthand for importing a library's primary file.

But it makes sense that the content of index.less would probably be @import "*.less"; for many Less libs once both are implemented.

Side note: I don't know why I thought this would break browser support. (Who knows, it was two years ago.) If it runs like stylus, an import line of @import "bootstrap"; can just as easily trigger an http request first to bootstrap.less, and, failing that, a request to "bootstrap/index.less".

[matthew-dean]

Since this issue was raised again in #2879 recently, part of the question was around what libraries do now. Many of them use the same .less name as the folder name. So if there are search fallbacks, it might make sense to do:

@import "library";

1. Try to import "library.less";
2. Try to import "library/library.less";
3. Try to import "library/index.less";

This would make a nicer shorthand for library imports than writing:

@import "library/library";

[thybzi]

The way you described (lib.less, then lib/lib.less, then lib/index.less) is just the best idea.
Better than current implementation in Stylus.
Love this and wait for this

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.