Open wbyoung opened 10 years ago
Thanks for the info! will do.
I haven't dug into what it would mean to just use browserify.
vinyl-source-stream's README actually uses browserify as an example.
That example doesn't include a way to pipe a stream into browserify
, though. Is that possible (and easy)?
According to browserify's docs you can pass a stream to browserify
:
For each file in files, if file is a stream, its contents will be used
And that works with gulp's File object? Again, haven't tried…
And that works with gulp's File object? Again, haven't tried…
No, but you can use something like event-stream's map
function to extract the contents from a stream of File objects. If the contents are a stream, you're done. If the contents are a buffer, you convert the buffer to a stream (there's a few different modules that can do this). There's also probably something in gulp-land that will do all this in one fell swoop.
Ok. Sounds a bit complicated which to me reaffirms there being a good cause for this plugin to exist.
I think if the plugin remains blacklisted, this repo should at least serve to document a recipe for that. If that recipe ends up being a good chunk of code, though, maybe this should come off the blacklist. Thanks for discussing, @gabegorelick. I hope the discussion can help @deepak1556.
If this plugin just enabled browserify
to deal with streams of Vinyl File objects, you probably wouldn't be blacklisted (at least I wouldn't blacklist it, not that I have any say). A lot of the issue is that the plugin does a lot more than that, e.g. transforms, shim, custom events, etc. The gulp people don't like plugins that do that.
/cc @hughsk
I'm still using gulp-browserify
... it's way easier to use in certain cases
I like being able to pass in a stream and just have it get browserified. I wouldn't mind a slimmed down version of this plugin that removes the extra bells and whistles so the plugin is not blacklisted. This plugin really fits my needs well because my build process does not run as a watch and I don't want minutes wasted with every build that I start. It's for my dev machine, so file caching is a viable option but in-process caching is not.
It appears that the gulp recommendation is to use watchify and convert the result into a vinyl stream. Another option is to cache and remember the files that get processed. Both cache in memory and do not solve my problem.
Personally, I'd rather use gulp-cache as a disk based cache and send files to gulp-browserify on cache misses, as addressed in this article. The article also links to this pull request, which gives more insight as to how granular the grunt developers want tasks.
After spending hours unsuccessfully trying to get Browserify not to kill my watch process on syntax errors, I decided to try this. Problem solved! The syntax was significantly improved as well.
Big +1 on getting this off the blacklist and keeping the project going.
What exactly does it even mean to be blacklisted?
It means that gulp does not think this plugin conforms to their ideals. They do not offer support for those plugins and they recommend that people do not use any blacklisted page.
More on blacklisting at https://github.com/gulpjs/plugins#blacklisting (from gulp's documentation).
See https://github.com/gulpjs/plugins/blob/master/src/blackList.json for the current blacklist.
Tyler Akins
On Thu, Sep 25, 2014 at 10:09 AM, Oliver Salzburg notifications@github.com wrote:
What exactly does it even mean to be blacklisted?
— Reply to this email directly or view it on GitHub https://github.com/deepak1556/gulp-browserify/issues/64#issuecomment-56832891 .
@fidian Thanks.
@mshick Agreed! My build system shouldn't die on syntax errors, it should just report the error and continue watching!
Just wanted to share that this plugin has been blacklisted by gulp.js suggesting to use the browserify module directly instead. I haven't dug into what it would mean to just use browserify. If it'd be difficult, perhaps you should open a pull request to take this off the blacklist.