Extracting logic to standalone node module

[0x-r4bbit]

Hey @karlgoldstein !

A few days ago I thought it could be a good thing to extract the main logic out of grunt-html2js and publish it as a standalone node module. The grunt task would rather be a wrapper to work with grunt.

Why? Because we now also have the gulp task runner and it could be a cool thing to have html2js in that env too :) wdyt?

[karlgoldstein]

Hi Pascal,

This is the first time I've heard of gulp; it looks cool. Looking at the
code for grunt-html2js, it is pretty tightly coupled to the grunt API
(filter/map, options, file, logging, error handling). Gulp appears to have
its own variants of all of these; if we tried to abstract them away in a
standalone module, I'm afraid we would wind up with more abstraction than
useful logic. I could get excited about a reusable abstraction layer that
could be used for other plugins, though.

So...given that the whole html2js task is just a few dozen SLOC, it seems
like writing another version of it for gulp would be most expedient. Or at
least start that way as a way to learn the gulp API/plugin authoring
pattern. Then if it makes sense, we could try to come up with a generic
abstraction layer for authoring plugins that work with either gulp or
grunt, and apply it to html2js.

wdyt?

On Fri, Dec 27, 2013 at 12:08 PM, Pascal Precht notifications@github.comwrote:

Hey @karlgoldstein https://github.com/karlgoldstein !

A few days ago I thought it could be a good thing to extract the main
logic out of grunt-html2js and publish it as a standalone node module. The
grunt task would rather be a wrapper to work with grunt.

Why? Because we now also have the gulp task runner and it could be a cool
thing to have html2js in that env too :) wdyt?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23
.

--Karl--

[0x-r4bbit]

@karlgoldstein well if you think the current logic is that much coupled to grunt api's... yea than it might be a good thing to just start right away with a gulp port. However, we'd introduce a lot of DRY code, so I think it'd be better to abstract it away. Maybe we can first somehow summarise where the code is coupled to grunt API's so we get a lil overview of the current state.

For a long term and for maintainability reasons it'd probably better to have one module that is wrapped by grunt/gulp tasks. Also, we'd open doors for other tools/scripts/process that could use html2js. :)

[bclinkinbeard]

I came to the Issues page to inquire about the same thing. My use case, however, is to potentially use atomify with Angular. I haven't looked at the source too closely yet but may give it a shot.

[marklagendijk]

Currently there are 3 Gulp plugins which do this:

1. gulp-html2js
2. gulp-angular-templatecache
3. gulp-ng-html2js (my one).

These all got written about the same time. As for me, I quickly looked through all the options this grunt plugin offers. To me it seems that most of those are not very useful / or not related to the core logic of the plugin. It seems to me that you never want to edit the generated code by hand, and therefore it doesn't matter that much how it looks etc.
That's the reason why my plugin is very simple. Another reason is that Gulp plugins should just do 1 thing, all other things can be done by another plugin.

So using my plugin could look like this:

gulp.src("./partials/*.html")
    .pipe(minifyHtml({
        empty: true,
        spare: true,
        quotes: true
    }))
    .pipe(ngHtml2Js({
        moduleName: "MyAwesomePartials",
        prefix: "/partials"
    }))
    .pipe(concat("partials.min.js"))
    .pipe(uglify())
    .pipe(gulp.dest("./dist/partials"));

From a general point of view it would indeed make sense to have a separate plugin which would just do the actual conversion of file contents. But considering how few lines of codes this actually is, I wonder whether that is worth it.

[rquadling]

Looking to close this issue. I have no experience with gulp. If you can present a PR, then I'd gladly look into it.

[rquadling]

Closing.