These are going to take some time, but I think these features are really going to shine:
First and foremost: I am thinking of plugins as just components actually, and maybe they should be treated as such.
One nice feature can be allowing plugin writers to add options to cli with descriptions and all that stuff. Right now for component-builder plugins, for browserify transforms, grunt tasks and duo plugins of course, Readme files are the only reference. Github & npm must be really getting some serious traffic just for this simple reason.
Think of it: ability to do simple stuff from cli, like duo plugin add sassduo plugin help sass, duo plugin search stuff may be a game-changer.
So, does duo really need npm for plugins? npm holds a barrier between plugins and duo builder. There's no way for builder to utilize plugins to an extent of controlling the entire build process; that's a one way relationship. But if we take the wheel on the other side, that introduces a lot of possibilities.
I don't know if these two are related, but since there are no manifest files, plugins are indeed one of the essential parts of the system. You see, one example is duo-sass apparently. Sass already knows how to import files, because it is the compiler itself, so what is the sense of using duo-sass over it? When you pass includePaths option you are already out of duo context, and like I said in @MatthewMueller's Edgeconf post, that generates more trouble than solutions.
That's why duo should introduce a different plugin ecosystem than Component or Browserify...
Maybe file-deps parser should handle this, or we can introduce some sort of pre-build craziness. I don't know, I couldn't really picture an easier method for any of these yet. So what do you guys think?
These are going to take some time, but I think these features are really going to shine:
First and foremost: I am thinking of plugins as just components actually, and maybe they should be treated as such.
One nice feature can be allowing plugin writers to add options to cli with descriptions and all that stuff. Right now for component-builder plugins, for browserify transforms, grunt tasks and duo plugins of course, Readme files are the only reference. Github & npm must be really getting some serious traffic just for this simple reason.
Think of it: ability to do simple stuff from cli, like
duo plugin add sassduo plugin help sass,duo plugin search stuffmay be a game-changer.So, does duo really need npm for plugins? npm holds a barrier between plugins and duo builder. There's no way for builder to utilize plugins to an extent of controlling the entire build process; that's a one way relationship. But if we take the wheel on the other side, that introduces a lot of possibilities.
I don't know if these two are related, but since there are no manifest files, plugins are indeed one of the essential parts of the system. You see, one example is duo-sass apparently. Sass already knows how to import files, because it is the compiler itself, so what is the sense of using duo-sass over it? When you pass
includePathsoption you are already out of duo context, and like I said in @MatthewMueller's Edgeconf post, that generates more trouble than solutions.That's why duo should introduce a different plugin ecosystem than Component or Browserify...
Maybe file-deps parser should handle this, or we can introduce some sort of pre-build craziness. I don't know, I couldn't really picture an easier method for any of these yet. So what do you guys think?