-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
about "plugins" and Streams [rambling] #31
Comments
You can already use event-stream (or other libraries) to wrap existing node-style (callback) libraries. Not sure this belongs in core. |
I agree that this just looks like event-stream and loses most of what makes
|
exactly, the point of these methods would be to convert the custom Stream data format: {
shortened: 'foo.md',
base: 'doc/',
path: 'doc/foo.md',
isDirectory: false,
stat: { ... },
contents: <Buffer 23 20 63 ...>
} into something that other tools would normally use (just the just cause in my opinion it will commit same mistakes as grunt eventually (many useful tools locked to a single runner for no real benefit). |
Plugins aren't locked in. As long as you pass the expected format stream,
|
@phated this is just an advice on how you guys could convert other npm modules into a compatible format without having to write custom plugins (and would also simplify the code of current plugins). |
@millermedeiros I like the idea but I think this belongs in userland. Core is reserved for base functionality not shims for supporting other styles of utilizing the base functionality. |
Especially if we are thinking of splitting out the file format and standardizing it. The compat layer for that standard shouldn't be in gulp |
just compare the plugin example on the README: var es = require('event-stream');
module.exports = function(header){
// check our options
if (!header) throw new Error("header option missing");
// our map function
function modifyContents(file, cb){
// remember that contents is ALWAYS a buffer
file.contents = new Buffer(header + String(file.contents));
// first argument is an error if one exists
// second argument is the modified file object
cb(null, file);
}
// return a stream
return es.map(modifyContents);
} with this implementation: var gulpMapper = require('gulp-mapper');
module.exports = function(header){
return gulpMapper.mapFileContentsSync(prepend, header);
};
function prepend(fileContents, str){
if (!str) throw new Error("header option missing");
return new Buffer(str + String(fileContents));
} think of it as a |
@millermedeiros Still the same opinion. IMO a function that makes writing plugins/streams easier doesn't need to be in core. It belongs in user-land and if proven useful enough in gulp-util |
@contra sure, it can be on user land as a |
@millermedeiros let me know when you have a repo up I'd love to help out |
@millermedeiros I just released a yeoman generator if you haven't started yet:
|
@hparra Nice! I'll try it out and give some feedback. I can put it in the README next to all of the plugin creation advice |
Streams are great to deal with large(ish) files and/or when you need to handle too much concurrency (cause memory), but it increases complexity (easier to explain callbacks than streams).
For what I know, most node.js libs are currently built around plain callbacks (
fn(data, callback)
) and doesn't benefit from Streams (wholedata
needs to be in memory before processing it).That got me thinking if writing and encouraging "plugins" is really the best way to go (which I don't think it is). For me it seems more useful to have a helper method that works as an adapter for existing tools than to force everyone to rewrite them as a plugin.
Thinking something like:
and modules would be just something like:
and:
needs
sync
andasync
versions of these methods.this is somewhat related to #28
The text was updated successfully, but these errors were encountered: