Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature proposal: @import (plugin) "myplugin.js" (or @plugin "myplugin.js") #2416

Closed
matthew-dean opened this issue Jan 27, 2015 · 5 comments

Comments

@matthew-dean
Copy link
Member

Surfacing this here as proposed by @rjgotten in #1861. "Plugins" were marked as implemented per that discussion, with anything not included in the plugin commit being deferred to a separate thread, so putting this proposal made during the discussion for housekeeping / any further discussion.

From @rjgotten:


Just to change things up; how about a declarative syntax to load "user mode" plugins from LESS style sheets themselves. Something like:

@import (plugin) "../plugins/my-plugin.js";

That would certainly open up possibilities for more heavy duty styling 'frameworks' without requiring customizing your installation with additional packages via npm, etc.

...The absolute easiest and most foolproof way to ensure a plugin is loaded is by picking it up as an import as part of the compilation process. Completely hands-off, no user-configuration required.

Other comments:

@calvinjuarez commented on Feb 26, 2014

As a non-lessc, pre-processor-style, CodeKit LESS user, I'm very in favor of a directive in the LESS file itself. I'd prefer to have a separate directive keyword (like, say @plugin), because I feel like the function of a plugin (augmenting how LESS works) is different to imports (affecting the output CSS). That's my 2¢.

@rjgotten
Copy link
Contributor

@matthew-dean
I have a proof of concept of the @import (plugin) "../plugins/my-plugin.js"; syntax working on the NodeJS side of things.

Fasted way to hammer it out was to place a hard require() call inside the ImportManager class, which works well enough. Ofcourse I really should set this up to work in an environment agnostic way. I have some ideas regarding how to set this up, but will have to see if they pan out.

Would you be interested in the work I've done sofar?

@seven-phases-max
Copy link
Member

Should not we close this since #2479? (There're some additional stuff to be implemented further like passing options to plugin and cli/@plugin interfaces unification, but I guess these are to be further feature-requests/issues to be ticked...)

@rjgotten
Copy link
Contributor

@seven-phases-max
Should not we close this since #2479?

I still have the #2522 pull request open. It fixes several scoping issues and provides more complete coverage in the unit test suite.

@lukeapage
Copy link
Member

lukeapage commented Mar 30, 2015 via email

@matthew-dean
Copy link
Member Author

Closing as #2479 and #2522 have been merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@lukeapage @matthew-dean @rjgotten @seven-phases-max and others