shouldn't it be just "less-plugins"?

[jonschlinkert]

Couldn't this be multiple plugins?

Love the fact that you made this happen! really exciting

[lukeapage]

If other language versions of less move under less/ then no, these wouldn't
be compatible.

[jonschlinkert]

got it, I can see the logic in that

[jonschlinkert]

After thinking about this more, I actually think it would be a good idea to put each plugin in its own repo, so that they are more easily found on GitHub (e.g. when a user searches for "autoprefix", this repo will never show in results). and it seems more idiomatic to the concept of having plugins to make them separate.

To make this easy, I could put a generator together so that new plugin repos can be created with yo less-plugin.

thoughts?

[lukeapage]

I think that would involve a lot of duplication.. think about testing and
boilerplate code or shared code. also we would get a lot of repositories
which could make it harder to find what you want.

On the other hand you might want plug-ins seperately for the browser if
some get big and yes it would make searching easier. For searching though I
was thinking we would have a section on the new website.

I still haven't decided how plugins get invoked for lessc.. does less have
a dependency on less-plugins or is there a new less-cli that depends on
both or does less plugins have a executable? I guess I'd rather there was
no hard dependency but if you globally install lessc and a plug-in, it got
found automatically.. but no idea how that would be achieved.

So I think I'd rather keep the simple plugins together and more complex
seperate? But I haven't decided completely so what do you think of the
above arguments?

[jonschlinkert]

I think I'd rather keep the simple plugins together and more complex seperate?

Yeah I like that thinking. based on that, here are a few thoughts:

1. have some built-in plugins that are in a single repo, call them "less-core-plugins" or "less-contrib-plugins" (which IMO would immediately identify them as being from the less.js core team, e.g. you). we're doing this with assemble with just a few plugins like "pagination", etc
2. for "non-core" plugins, we can use the convention less-plugin-*. Search-wise, nothing can beat having the plugins individually listed on Github's (and npm's) search results. don't forget about APIs that consume search data from both platforms - if the plugins aren't listed out, people won't find them unless they know to go to the website to look. generally we'll want people to stumble acoss them when they're searching for the term. e.g. if a user searches for "vendor prefixes" we want our plugin to come up. Also, regarding listing the plugins on the site I created a grunt task that would pull down the list of plugins and generate the list automatically. this would still be possible if they plugins in one project, but IMO it would be easier if they are separate.
3. Don't worry too much about the code duplication. generators and boilerplates make that easy to maintain. and the trend is towards smaller more compact modules, versus larger ("monolithic") libraries. no news there, but one side benefit of this that might not be obvious is that bug reports are usually more focused and easier to fix as a result, feedback is better, and pull requests happen more often (vis-a-vis features "hidden" in larger libraries)

I still haven't decided how plugins get invoked for lessc.. does less have a dependency on less-plugins or is there a new less-cli that depends on both or does less plugins have a executable?

How about:

• a plugins option, allowing an array of plugins to be registered with less.js.
• "core" plugins could be registered the same way, but would be included as dependencies or peerDependencies of less.js

[lukeapage]

Hi Jon,
Sorry I never get back to you, I'm broadly in agreement.
Questions:

1. If you add the core plugins to your package.json how does the user specify which plugins to use? Does that mean we should seperate out the plugins?
2. How do plugins get available to lessc globally? I have no idea how other repos do it. Obviously referencing from a package.json is fine if you are running as part of that package but would the global lessc look to see if there is a package.json in the current directory?

Any pointers to how existing packages manage this would be great.

[jonschlinkert]

I think the first challenge is the API for plugins, what is exposed on the less object, etc. I think 3rd party libs should do most of the heavy lifting when it comes to "how" plugins are registered. For example, if on node.js you might use grunt-contrib-less, which would load plugins and "register" them with Less.js.

Regarding globally available plugins, that might not be something we want to do yet (or ever). The main problem we'll run into with globally installed plugins is version incompatibles with local packages. So at least for the short-term, enforcing that plugins need to be installed on a project-by-project basis would be the safest way to go. And pragmatically, by nature a plugin is covering something that probably doesn't belong in core Less.js, so from that standpoint it also doesn't make sense to install it globally.

This makes me wonder, what do you think about breaking out the CLI into another repo, like less-cli or whatever. then the CLI could be installed globally, but less.js itself and/or plugins could be installed on a project-by-project basis. I think the CLI might get more love and attention from node.js devs (e.g. contributions) in this scenario too.

[Synchro]

I think I'd be quite keen on loading plugins specified from Less files, rather than configuring the environment they are loaded from. That way you would only load the plugins you needed (perhaps with dependency resolution done internally), and each project could specify its own plugins wthin a single global environment. Something like:

require 'my.plugin.js'
color: my-plugin();

[jonschlinkert]

I think I'd be quite keen on loading plugins specified from Less files, rather than configuring the environment they are loaded from.

ha, that's very similar to what I was thinking (which is what led to my comment about import statements, less/less.js#1861 (comment)). I actually created a proof of concept of this months ago on assemble-less. I think it's still on a branch.

But backing up a bit, I think that the recognition of the require statement in a less file is also a good example of something that could or should be handled by a plugin.

[matthew-dean]

I would be somewhat against a require statement IN the Less file (seems like something that should be part of your options file, which we should probably finish work on). But depends on how it's done.

[jonschlinkert]

I would be somewhat against a require statement IN the Less file

Exactly my point. This should be a plugin, b/c I would absolutely love to have it. I have mixins I've been using that haven't changed a line in two years. IMO it's a perfect use case for these.

[jonschlinkert]

we can technically already do this kind of thing now. here is an example (although this is only modifying a path, I see no reason why a similar function couldn't inject a string into the file), see:

• https://github.com/assemble/assemble-less/blob/master/test/fixtures/customFunctions.less#L5, and
• https://github.com/assemble/assemble-less/blob/master/Gruntfile.js#L319-L326

So I think the big "payoff" with plugins will be the ease-of-registration and working with the API.

this is interesting... ideas are flying now!

[lukeapage]

been thinking alot about this and came to the conclusion that having one repo per plugin was good. less can pull in a plugin using a single option.
e.g. lessc --inline-urls will search for a package named "less-plugin-inline-urls" and it can also provide the mechanism to pass options.

[matthew-dean]

I'm interpreting that to mean that it would search Github? Since you're talking about a repo per plugin? A few questions:

1. Would that be organization-independent? That is, could I develop a less plugin under http://github.com/matthew-dean/less-plugin-svg-awesome and load it via lessc --svg-awesome? And what happens if I develop a plugin called less-plugin-source-map or less-plugin-clean-css? That is, how do we support plugin development without centrally managing, and how do you prevent current or future naming conflicts?
2. How do you distinguish local plugins from github hosted ones in the compiler options?
3. Once I was won over on the concept of @import (plugin) syntax in less files, I'm eager to see that support for people who don't use lessc. What do we feel is the best syntax for remote/local loading of plugins inline?

[jonschlinkert]

it would search Github

I think some of us are considering what plugins could/might do from different angles. I think anyone will be able to create plugins, but (correct me if I'm wrong with every thing I'm about to say @lukeapage) whether or not the plugins are from user-land or the less core team they would be registered/loaded the same way. e.g. I don't think there are any plans to automatically find plugins on github and load them. This next part I'm not as clear on, but I think the plan is to load plugins that are either explicitly specified/registered in the user's config (which could be in less files themselves or whatever), or - with the node at least - perhaps automatically registered when plugins are specified in package.json.

My suggestion is that we don't do automatic loading of plugins. I've mentioned this before, but I think auto-loading is best left to user-land, regardless of platform. A good analogy is grunt and gulp plugins. By default, users are expected to explicitly define/require plugins in their configs, but there are a number of user-created projects with different approaches for auto-loading plugins.

One last thought is that, IMHO, the focus for plugins should be on implementors, not end-users per se. If we make it easier for implementors to use plugins in, say, an express middleware, or gulp/grunt plugins, then by making this easier for a handful of implementors we will have effectively enabled thousands of end users to get the benefits of any plugins used - without having to worry about how they were used. Not to mention, it would be easy for gulp-less or grunt-contrib-less to allow users to register plugins in the config/options of either tool.

just my 2c

[lukeapage]

It won't search npm. It will require a module at the same level as less is
at. So a end user does npm install less, npm install less-plugin-cleancss,
then lessc --cleancss. As well as the shortcut I will provide an option to
load a plug-in directly (so it doesn't need to begin less-plugin that's
just a shortcut).
Programatically a node plugin is just a object with an install method that
gets less and a plug-in manager. It can then register multiple plugins if
needed. In other environments its up to whomever implements that
environment to create less.PluginManager and connect with a plugin. So what
something is named and any node specifics are only relevant to lessc and
the node specific part of less.
So 1) yes. It's up to the user and npm though. If someone else registers
the name first, don't use npm or chose a different name. 2) I don't
understand, your question doesn't make sense 3) nothing I've done excludes
that syntax, if you want it, have a go at developing that feature and
submit a pull request.
As I've said before, rather than ask me lots of questions, it's easier if
you spend some time looking at the code. I've thought a lot about what
people have said in the past and I'm trying to take all use-cases into
account.

[matthew-dean]

Thank you for the taking the time to respond. My thinking is usually that looking at the code may indicate where a feature is at, but sometimes it doesn't communicate where a feature is going, so sometimes a first-hand account is more helpful.

That said, would it be possible to start a v2 of less-docs to get feature documentation? That might communicate a bit more clearly than via code, and save you the frustration of answering as many questions.

[seven-phases-max]

That said, would it be possible to start a v2 of less-docs to get feature documentation?

Assuming that for the moment only @lukeapage can document these things, starting it right now will kill both :) ( I mean both v2 code and v2 docs). No need to panic though, I guess most of these questions and problems will answer/solve themselves as soon as we start to use these things.