shannonmoeller / gulp-hb

A sane Gulp plugin to compile Handlebars templates. Useful as a static site generator.
http://npm.im/gulp-hb
MIT License
147 stars 14 forks source link

Parentheses throws error #33

Closed efender closed 8 years ago

efender commented 8 years ago

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" )

shannonmoeller commented 8 years ago

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 })
efender commented 8 years ago

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 ) );
}
shannonmoeller commented 8 years ago

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
shannonmoeller commented 8 years ago

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.

efender commented 8 years ago

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?

shannonmoeller commented 8 years ago

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.

efender commented 8 years ago

Ок, thanks!

shannonmoeller commented 8 years ago

My pleasure!

shannonmoeller commented 8 years ago

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

efender commented 8 years ago

Yes, now debug output is clean ) Thanks!

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