shannonmoeller / gulp-hb

A sane Gulp plugin to compile Handlebars templates. Useful as a static site generator.

Home Page:http://npm.im/gulp-hb

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Parentheses throws error

efender opened this issue · comments

If project path has parenthesis than the plugin (v. 4, but not v.2.6.5) throws error, e.g. "(folder) name":

# ./(folder) name
# ./(folder) name/gulpfile.js
events.js:154
      throw er; // Unhandled 'error' event
      ^
Error: Missing partial: 'layouts/base' ...

But without parenthesis ("folder name") it's ok

P.S. Thanks for your great plugin )

update: sorry for my english, not "braces", but "parenthesis" )

I think it might be that the partial names are different now. The way partials are named is a bit different than it used to be. See the section Exporting a Function in the handlebars-wax README.

Try adding the debug flag to your options and double check that your partials are registered as you expect:

hb({ debug: true })

But without parenthesis it works!
Little more error log:

Error: Missing partial: 'layouts/base'
    at Object.helpers.extend (/path-to-project/(test)/node_modules/handlebars-layouts/index.js:122:11)

I append console.log at handlebars-layouts/index.js:
1455889305111
Log for project "(test)" (with parenthesis):

{ '(test)/src/view/partials/blocks/footer': { [Function: ret] _setup: [Function], _child: [Function] },
  '(test)/src/view/partials/blocks/head': { [Function: ret] _setup: [Function], _child: [Function] },
...
  '(test)/src/view/partials/layouts/base': { [Function: ret] _setup: [Function], _child: [Function] } }

Log for project "test" (no parenthesis):

{ 'blocks/footer': { [Function: ret] _setup: [Function], _child: [Function] },
  'blocks/head': { [Function: ret] _setup: [Function], _child: [Function] },
...
  'layouts/base': { [Function: ret] _setup: [Function], _child: [Function] } }

One task, one project (only project name with and w/o ()) but different return:
(test)/src/view/partials/blocks/footer vs 'blocks/footer

It may help?


And debug log is very strange (full log):
1455889776675

My gulp task:

import c from '../config';
import {
    gulp, data, fm, hb, rename
} from '../imports';

export default function handlebarsTask() {
    const hbStream = hb(
        {
            debug: true,
            bustCache: true
        } )
        .partials( c.src + '/view/partials/**/*.hbs' )
        .helpers( 'node_modules/handlebars-layouts/index.js' )
        .helpers( c.src + '/view/helpers/**/*.js' )
        .data( c.src + '/view/data/**/*.{js,json}' );

    return gulp
        .src( c.src + '/view/pages/**/*.hbs' )
        .pipe( data( function ( file ) {
            return require( file.path.replace( '.html', '.json' ) );
        } ) )
        .pipe( fm( { property: 'data.fm' } ) )
        .pipe( hbStream )
        .pipe( rename( function ( path ) {
            path.extname = '.html';
            return path;
        } ) )
        .pipe( gulp.dest( c.dest ) );
}

Yep. This is the expected behavior. Parentheses are considered glob characters (see node-glob: Glob Primer). Partial names are derived from the non-glob portion of a given path using glob-parent.

// Without the parentheses
.partials('test/view/partials/**/*.hbs');
//                            └─ glob starts here

// With the parentheses
.partials('(test)/view/partials/**/*.hbs');
//         └─ glob starts here

The debug output is long because it looks like the debug flag is passed all the way down to node-glob. I'll look into that. The gulp-hb-specific portion is at the bottom and displays what you're logging:

  main.hbs
    context:
      settings
    data:
      fm
    decorators:
      inline
    helpers:
      add
      ...
      with
    partials:
      blocks/footer
      blocks/head
      blocks/header
      blocks/popups
      blocks/scripts
      blocks/sidebar
      blocks/vk_widget
      layouts/base

In v2, partials were named according to the unique portion of a path, regardless of where the globbing happened. While this worked as expected in certain cases, it led to cases where paths would change in unexpected ways simply by creating new partials:

test/view/partials/layouts/foo.hbs
test/view/partials/layouts/bar.hbs
                           └─ unique portion starts here

// ... add some partials ...

test/view/partials/components/foo.hbs
test/view/partials/components/bar.hbs
test/view/partials/layouts/foo.hbs
test/view/partials/layouts/bar.hbs
                   └─ unique portion now starts here

Standardizing on globbed portions of paths and introducing the fluent API gave users the ability to predictably and granularly control exact names of data keys, partials, helpers, and decorators. My hope is that this will be less confusing down the road.

So, I can't use parenthesis in folder names anymore?
I should revert back to v.2? )

Maybe It possible to escape symbols in project path?

Because this is core glob syntax, I would recommend against using parentheses in paths in favor of an alternate pattern. Perhaps _test instead of (test)?

If you really wish to continue using parentheses, you may provide your own parsePartialName callback. The original logic can be found in the v1 branch of require-glob.

Ок, thanks!

My pleasure!

@efender FYI, I've addressed the issue with debug being too noisy and released as v4.0.3.

Yes, now debug output is clean )
Thanks!

P.S. I replaced parentheses by equals (name1) name2 -> =name1= name2.