Duplicate of gulp-smoosher about gulp-inline HOT 20 CLOSED

It's very similar, but not identical. I originally wanted to use his, but I ended up creating my own because I wanted the ability to transform the inlined files before they were inserted into the document.

EDIT: This allows you to simply tack the inline task onto your development build to create a production build.

from gulp-inline.

Understood. You still should work with the author to either add that functionality or deprecate his plugin in favor of yours. The gulp ecosystem does not need two plugins that do exactly the same thing with slight differences, it creates fragmentation and duplication of effort, and one of your plugins is bound to get blacklisted by the gulp team.

from gulp-inline.

@gabrielflorit I think being able to transform the files before they are injected is an important feature (and provides a way to actually solve that issue I reported to you before in a modular way), and I feel like my name for this plugin is a little bit more intuitive. You made your module first though, so if you want to implement this feature i'll take mine down if you want to use this name.

from gulp-inline.

I agree with you - it is an important feature. My only hesitation is that the Gulp guidelines strongly recommend plugins do only one thing - see https://github.com/gulpjs/gulp/blob/master/docs/writing-a-plugin/guidelines.md . I use @jonkemp 's https://github.com/jonkemp/gulp-useref to do js / css minification before invoking the inline/smoosh task.

I'd love to hear more opinions on this - @jonkemp @sindresorhus ?

from gulp-inline.

@gabrielflorit 👍

I agree with @lazd and @gabrielflorit. Plugins should not duplicate other plugins.

Plugins should also only do one thing. If there is something you need that doesn't exist, discuss it first before creating a new plugin.

from gulp-inline.

@jonkemp I would argue that this plugin is not actually doing more than one thing. It's providing hooks so that other plugins can do other things.

from gulp-inline.

@ashaffer Fair enough. It still seems to me like your files could be minified in your build task before calling your plugin so I don't see how it's needed.

from gulp-inline.

@jonkemp There are two reasons I see for using it. The first is purely aesthetic, in some cases I just think its cleaner to structure it this way. It allows you to contain your entire production pipeline in a single add-on task that transforms the output of a development build (but it doesn't force this on anyone, either).

The second reason is that HTML doesn't respect javascript comment syntax. This means that if you are trying to inline a script that contains this:

/* </script> */

Then the resultant html will be broken (angular.js, for instance, contains such a comment). One approach to solving this problem is transforming your js in some way prior to inlining it (e.g. stripping comments). And while it is possible that you could just state in the documentation that all js and css files must be pre-processed in such a way that this issue is resolved, it seems more appropriate to me for the inline plugin itself to export hooks for resolving an issue like this, since they are so related (the solution in production could simply be minification, which strips comments, but in development some less-severe variety of mangling may be desirable).

from gulp-inline.

@ashaffer could you just minify the HTML file after everything is inlined?

from gulp-inline.

@jonkemp Unfortunately, no. Once they are combined, the parse becomes ambiguous. In order to be done correctly, any transformations must happen prior to inlining.

from gulp-inline.

I think we should investigate using a setup like gulp-useref - see his integration with gulp-filter.

from gulp-inline.

@gabrielflorit How would that work?

from gulp-inline.

@ashaffer gulp-useref, in combination with gulp-filter, allows you to specify transformations to js/css before they are concatenated. If I understand your usecase correctly, you could easily modify your pipeline so the following happens:

gulp-useref runs through the html file and combines .js files to combined.js -> you pass in a function to strip comments from combined.js -> gulp-useref writes combined.js back onto the html file -> invoke smoosher to inline combined.js into html file .

from gulp-inline.

@gabrielflorit That seems like the right approach to me. I'm not sure how that could be implemented properly though. Smoosher has to take the html as its input stream, so how would you get it the js/css files that it needs?

To borrow the example from gulp-useref's page:

gulp.task('html', function () {
    var jsFilter = filter('**/*.js');
    var cssFilter = filter('**/*.css');

    return gulp.src('app/*.html')
        .pipe(useref.assets())
        .pipe(jsFilter)
        .pipe(uglify())
        .pipe(jsFilter.restore())
        .pipe(cssFilter)
        .pipe(minifyCss())
        .pipe(cssFilter.restore())
        .pipe(useref.restore())
        .pipe(useref())
        .pipe(smoosher())   // smoosher doesn't know about the minified css/js assets
        .pipe(gulp.dest('dist'));
});

One solution could be that smoosher just waits until it receives files that match the script/link elements it sees in the html? Any thoughts?

from gulp-inline.

@ashaffer In my setup I first wrap the tags with smoosher, then build. e.g.:

<!-- smoosh -->
<!-- build:js .tmp/combined.js -->
<script src='js/globe.graphic.js'></script>
<script src='js/init.js'></script>
<!-- endbuild -->
<!-- endsmoosh -->

from gulp-inline.

@gabrielflorit Right, but in order for that to work, useref would have to write its files out to disk first, right? Which is somewhat contrary to the premise of gulp. Unless i'm misunderstanding you or missing the way you intend it to work.

from gulp-inline.

Indeed, in the snippet above, useref will parse through the html, find the 2 script tags inside <!-- build -->, combine them, run a minifier, write combined.js to disk, also modify the html, then smoosher will run through the html and inline the contents of combined.js.

from gulp-inline.

Ya, that's what I was trying to avoid, because it requires synchronization between two separate tasks (which gulp is not great at) and requires an intermediate disk write (which avoidance of is one of the primary reason for using streams).

What do you think about smoosher simply waiting to receive combined.js as another data event? The pipeline could look just like the pipeline for useref I described above. Smoosher could essentially just wait until it has received file objects that satisfy all the dependencies listed in each html file it has received, and once it has received those dependencies, it emits the smooshed file. This would make it compose with useref and filter in a streaming pipeline.

from gulp-inline.

@ashaffer I wonder if you can make your plugin work like this?
gulpjs/gulp#239 (comment)

From contra

@robrich Plugins aren't limited to being just processors in the streams. They can be the head and the tail too.

someplugin('file.html')
  .pipe(otherplugin())
  .pipe(gulp.dest('folder'))
  .pipe(someplugin.dest('stuff.html'))

Just make sure your head puts out vinyl objects, and your tail (if you make one) accepts vinyl objects so it works within the ecosystem

from gulp-inline.

What I like on this plugin over smoosher that it does not need any additional HTML comments. So thanks for it, I was already prepared to write it myself. And BTW I have same problem with gulp-useref too.

from gulp-inline.