Access to root context in partials and helpers #392

merged 1 commit into from Jan 15, 2014


None yet

There is already a related bug about getting parent context inside a partial called from within a block helper: issue #182. However, tracking parent context is probably not enough - add in another block helper (e.g. an if inside an each) and things quickly get out of hand.

The same story with helpers - it's easy enough to get current context via this, it's easy enough to pass in parent context via ".." - but once again, very quickly it becomes "../../../.." There is a hack proposed in issue #245 but I had mixed fortune with it.

The above two problems seriously affect code re-use - one must always keep track of context and nesting. There are pull requests for parentContext by introducing helpers and passing explicit parent context. While I find that useful, I also need the global context - just a couple of sample use cases: localization (must know which language to use), changing some item layout/details based on user status (essentially access check, although some might argue this is "logic" and should thus not be done inside a template).

It would be great to have access to global/root context at all times - inside an {{#each}}, inside an {{#if}}, inside any helper that I create myself and naturally inside any partials that may be nested inside block helpers.

This is just one example of how badly "../" can get out of hands:

I realize this is probably correct behavior - there's no "rootItem" inside the each, so "../rootItem" does not exist inside the if inside the each, but if one tried to add a nested loop, and an if in there... you get the point.

Another reason to support root access might be Handlebars' claim that 'Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars'. The Mustache enginges for both php and js seem to support access to root context (see for js version), so one might expect Handlebars to do so as well.

However, the strongest reasons for support are the use cases you describe above + the pain of keeping track of parent depth.


Mustache.js has a nice way of dealing with this. It essentially looks for the named property in the current context, if it can't find it, it will traverse back up the context tree all the way to the root checking each parent context for the named property, and uses the first one it finds.



{{ #items }}
    <li>Item {{.}} for {{user}}</li>
{{ /items }}


    items: [1,2,3,4,5],
    user: 'Ash'


    <li>Item 1 for Ash</li>
    <li>Item 2 for Ash</li>
    <li>Item 3 for Ash</li>
    <li>Item 4 for Ash</li>
    <li>Item 5 for Ash</li>

I think this would be a great addition to Handlebars and would bring it more inline with Mustache.js

Of course in the case where you are looking a property on the root which shares a name with a property somewhere in your context tree it will only return the closest property to you.

It might be useful to have a special keyword tag e.g {{ root }}. That always references the root Object. That way you can call out the {{ root.someProperty.SomeChild }} anywhere in your template. similarly using it in a section will switch the context of that section back to the root context.


{{# outerProp }}
    {{# innerProp }}
        {{#root }}
            {{# outerProp.innerProp }}
            {{/ outerProp.innerProp }}
    {{/ innerProp }}

Although I feel like this would be a rarer case than the first solution, which comes in handy quite a lot. Where as I have yet to find a situation where I have nested properties with the same names.

I opened a pull request which makes it simple to access the root context in custom helpers:



jonschlinkert commented May 20, 2013

Yeah we just had an issue on Assemble related to this, assemble/assemble#164.

clavery referenced this pull request in clavery/grunt-generator Jun 17, 2013


Retrieving global options from helpers.js #6

Snugug commented Jun 17, 2013

👍 for this as well. It's recently bit me not being able to access root.

👍 I would like to request this too. I have an each statement which iterates over a 2D array and using "../" doesn't work. I have a nested if statement so have tried "../../" and that too doesn't work. If there isn't performance overhead to adding a root keyword then it's a quick win.


jonschlinkert commented Jul 30, 2013

Would love to see some kind of acknowledgement of this issue. It has been an ongoing problem for us with assemble.


kpdecker commented Jul 31, 2013

This is a non-trivial implementation that none of the core team has had a time to look at. It has not been closed as it is something that we would like to do. Pull requests are welcome.


kpdecker commented Jul 31, 2013

Note that there are many issues to consider with this such as arbitrary nesting vs. blanket root access vs. work-around such as using @ data var (as well as the similar issue of how/if data vars should support traversal.


jonschlinkert commented Aug 14, 2013

Note that there are many issues to consider with this such as arbitrary nesting vs. blanket root access vs. work-around such as using @ data var

@kpdecker perhaps you could put an issue up with some bullets to discuss and socialize with the community? then we can try to systematically attack the problem and gain consensus on each point.


kpdecker commented Aug 14, 2013

@jonschlinkert working through all of the issues is one of the major tasks here. I'll try to prioritize this higher but as a volunteer on an OSS project with only so many hours in the day its tough.


jonschlinkert commented Aug 14, 2013

👍 I hear you there

I can see two points here:

  • a feature for easy access root context in any nested helper/block/etc - this would be a very helpful, because traversing with "../" is error-prone.
  • issues with current behaviors of block helpers - i.e. when we have to add ".." to go out current context of ANY block helper. So N nested "if will create N nested contexts. Such behavior was very confusing for me when I encountered with it even after more than a year of using HB. I really didn't understand that even "if creates nested context. I even created a bug #601 which makes no sense indeed (BTW: it's very long way to build and run tests for HB because of need to install node, ruby, ruby devtools (!), rake and other gems).
    So I'd say that this's a bug (even if it's by design). Wouldn't it make sense to not nest a block's context if it hasn't changed? Not every helper can change context.

jonschlinkert referenced this pull request in helpers/handlebars-helpers Sep 12, 2013


Get page variable in nested block helpers #62


jonschlinkert commented Jan 8, 2014

@kpdecker, could subexpressions be used to achieve this? Looks like it should might, but I haven't had a chance to test. thanks!


kpdecker commented Jan 8, 2014

@jonschlinkert strawman? I think the simplest solution here is to just add @root variable to the data object but I'm hesitant to do that until the depthed question is answered sufficiently.


jonschlinkert commented Jan 8, 2014

Strawman implies that I was putting forth some kind of argument, which I'm assuming is a result of me using the word "should" instead of "might". If that's the case, sorry for the confusion. I wasn't stating that "subexpressions ought to be used to achieve this", just asking "if they could be".

Also, now that I've looked more closely at subexpressions I think my initial (incorrect) interpretation was the inverse of how they actually work. Regardless, the feature still looks awesome, a great addition to Handlebars. Anyway, sorry about the confusion.


kpdecker commented Jan 13, 2014

@jonschlinkert no worries. I think something like or similar is going to be the best route for this, which can actually be implemented outside of the library itself it people want to play around with that.

doowb commented Jan 14, 2014

@kpdecker we have this pending PR on assemble-handlebars, and I'm wondering if this looks like it could solve the issue.

I think it would allow doing... {{}} from any place, but I haven't had a chance to test it yet.


jonschlinkert commented Jan 14, 2014

@kpdecker I know you're super busy, but would you mind just glancing at the PR to give us your insight as to whether or not this is a good approach? nothing detailed.


kpdecker commented Jan 15, 2014

@doowb @jonschlinkert Why not just do I'm not a fan of that solution as it could conflict with context variables named root and creates a lookup that could surprise people if they don't know to expect this.


jonschlinkert commented Jan 15, 2014

@kpdecker makes sense thanks. so just use createFrame?


jonschlinkert commented Jan 15, 2014

ah, nice. I was actually asking if createFrame is what I should use, I need to take more time on my replies! sorry

@kpdecker kpdecker added a commit that referenced this pull request Jan 15, 2014

@kpdecker kpdecker Merge pull request #392 from wycats/root-data
Access to root context in partials and helpers

@kpdecker kpdecker merged commit cb80f46 into master Jan 15, 2014

1 check passed

default The Travis CI build passed

kpdecker deleted the root-data branch Jan 15, 2014

ericf commented Jan 15, 2014

Sweet! Glad to see this merged.

Can somebody please show us how the API works?

If it's @root then how do we use it to access data?

I'm hoping it's {{root.SomeData}} ?

Does this get passed down to partials somehow?


kpdecker commented Jan 15, 2014

@BrewDawg {{@root.someData}} see the tests.
@jessehouchins it should. If it's not I would consider that a bug

doowb commented Jan 15, 2014

@kpdecker Thanks for merging this. I'm glad to see this in the main branch instead of us trying to do something that would cause conflicts.That's exactly why I was asking for your advice on the other PR.

nopr commented Jan 29, 2014

@kpdecker Good stuff. Do you have an estimate on when this might make an appearance in the next npm release for those of us using grunt?

jezell commented Feb 3, 2014

+1 this is awesome. push it!


kpdecker commented Feb 10, 2014

Released in v2.0.0-alpha.1


jonschlinkert commented Feb 10, 2014

👍 !

nopr commented Feb 10, 2014


jezell commented Feb 10, 2014


Very late on this but wouldn't it be more idiomatic/efficient to keep using the tree traversal notation to access top-level variables instead of introducing a new syntax? Like so:

{{ /someVar }}
{{ /someOther.var }}

I'm not seeing any documentation on how the root is used/called upon within a helper. Could someone post an example and/or update the documentation?

yeah! how to get root in partials and blocks?

DenisMir referenced this pull request in assemble/assemble Nov 20, 2014


Handlebars Latest Version #593

@kkirsche kkirsche added a commit to kkirsche/ that referenced this pull request Feb 10, 2015

@kkirsche kkirsche Update handlebars from 1.0.0-rc.4 to 3.0.0
Update handlebars from 1.0.0-rc.4 to 3.0.0

## v3.0.0 - February 10th, 2015
- [#941](wycats/handlebars.js#941) - Add support for dynamic partial names ([@kpdecker](
- [#940](wycats/handlebars.js#940) - Add missing reserved words so compiler knows to use array syntax: ([@mattflaschen](
- [#938](wycats/handlebars.js#938) - Fix example using #with helper ([@diwo](
- [#930](wycats/handlebars.js#930) - Add parent tracking and mutation to AST visitors ([@kpdecker](
- [#926](wycats/handlebars.js#926) - Depthed lookups fail when program duplicator runs ([@kpdecker](
- [#918](wycats/handlebars.js#918) - Add instructions for 'spec/mustache' to, fix a few typos ([@oneeman](
- [#915](wycats/handlebars.js#915) - Ast update ([@kpdecker](
- [#910](wycats/handlebars.js#910) - Different behavior of {{@last}} when {{#each}} in {{#each}} ([@zordius](
- [#907](wycats/handlebars.js#907) - Implement named helper variable references ([@kpdecker](
- [#906](wycats/handlebars.js#906) - Add parser support for block params ([@mmun](
- [#903](wycats/handlebars.js#903) - Only provide aliases for multiple use calls ([@kpdecker](
- [#902](wycats/handlebars.js#902) - Generate Source Maps ([@kpdecker](
- [#901](wycats/handlebars.js#901) - Still escapes with noEscape enabled on isolated Handlebars environment ([@zedknight](
- [#896](wycats/handlebars.js#896) - Simplify BlockNode by removing intermediate MustacheNode ([@mmun](
- [#892](wycats/handlebars.js#892) - Implement parser for else chaining of helpers ([@kpdecker](
- [#889](wycats/handlebars.js#889) - Consider extensible parser API ([@kpdecker](
- [#887](wycats/handlebars.js#887) - Handlebars.noConflict() option? ([@bradvogel](
- [#886](wycats/handlebars.js#886) - Add SafeString to context (or use duck-typing) ([@dominicbarnes](
- [#870](wycats/handlebars.js#870) - Registering undefined partial throws exception. ([@max-b](
- [#866](wycats/handlebars.js#866) - comments don't respect whitespace control ([@75lb](
- [#863](wycats/handlebars.js#863) - + jsDelivr CDN info ([@tomByrer](
- [#858](wycats/handlebars.js#858) - Disable new default auto-indent at included partials ([@majodev](
- [#856](wycats/handlebars.js#856) - jspm compatibility ([@MajorBreakfast](
- [#805](wycats/handlebars.js#805) - Request: "strict" lookups ([@nzakas](

- Export the default object for handlebars/runtime - 5594416
- Lookup partials when undefined - 617dd57

Compatibility notes:
- Runtime breaking changes. Must match 3.x runtime and precompiler.
- The AST has been upgraded to a public API.
  - There are a number of changes to this, but the format is now documented in docs/
  - The Visitor API has been expanded to support mutation and provide a base implementation
- The `JavaScriptCompiler` APIs have been formalized and documented. As part of the sourcemap handling these should be updated to return arrays for concatenation.
- `JavaScriptCompiler.namespace` has been removed as it was unused.
- `SafeString` is now duck typed on `toHTML`

New Features:
- noConflict
- Source Maps
- Block Params
- Strict Mode
- @last and other each changes
- Chained else blocks
- @data methods can now have helper parameters passed to them
- Dynamic partials


## v2.0.0 - September 1st, 2014
- Update jsfiddle to 2.0.0-beta.1 - 0670f65
- Add contrib note regarding docs - 4d17e3c
- Play nice with gemspec version numbers - 64d5481


## v2.0.0-beta.1 - August 26th, 2014
- [#787](wycats/handlebars.js#787) - Remove whitespace surrounding standalone statements ([@kpdecker](
- [#827](wycats/handlebars.js#827) - Render false literal as “false” ([@scoot557](
- [#767](wycats/handlebars.js#767) - Subexpressions bug with hash and context ([@evensoul](
- Changes to 0/undefined handling
  - [#731](wycats/handlebars.js#731) - Strange behavior for {{#foo}} {{bar}} {{/foo}} when foo is 0 ([@kpdecker](
  - [#820](wycats/handlebars.js#820) - strange behavior for {{}} when foo is 0 or null or false ([@zordius](
  - [#837](wycats/handlebars.js#837) - Strange input for custom helper ( == false when foo is undefined ) ([@zordius](
- [#819](wycats/handlebars.js#819) - Implement recursive field lookup ([@kpdecker](
- [#764](wycats/handlebars.js#764) - This reference not working for helpers ([@kpdecker](
- [#773](wycats/handlebars.js#773) - Implicit parameters in {{#each}} introduces a peculiarity in helpers calling convention  ([@Bertrand](
- [#783](wycats/handlebars.js#783) - helperMissing and consistency for different expression types ([@ErisDS](
- [#795](wycats/handlebars.js#795) - Turn the precompile script into a wrapper around a module. ([@jwietelmann](
- [#823](wycats/handlebars.js#823) - Support inverse sections on the with helper ([@dan-manges](
- [#834](wycats/handlebars.js#834) - Refactor blocks, programs and inverses ([@mmun](
- [#852](wycats/handlebars.js#852) - {{foo~}} space control behavior is different from older version ([@zordius](
- [#835](wycats/handlebars.js#835) - Templates overwritten if file is loaded twice

- Expose escapeExpression on the root object - 980c38c
- Remove nested function eval in blockHelperMissing - 6f22ec1
- Fix compiler program de-duping - 9e3f824

Compatibility notes:
- The default build now outputs a generic UMD wrapper. This should be transparent change but may cause issues in some environments.
- Runtime compatibility breaks in both directions. Ensure that both compiler and client are upgraded to 2.0.0-beta.1 or higher at the same time.
  - `programWithDepth` has been removed an instead an array of context values is passed to fields needing depth lookups.
- `false` values are now printed to output rather than silently dropped
- Lines containing only block statements and whitespace are now removed. This matches the Mustache spec but may cause issues with code that expects whitespace to exist but would not otherwise.
- Partials that are standalone will now indent their rendered content
- `AST.ProgramNode`'s signature has changed.
- Numerious methods/features removed from psuedo-API classes
  - `JavaScriptCompiler.register`
  - `JavaScriptCompiler.replaceStack` no longer supports non-inline replace
  - `Compiler.disassemble`
  - `DECLARE` opcode
  - `strip` opcode
  - `lookup` opcode
  - Content nodes may have their `string` values mutated over time. `original` field provides the unmodified value.
- Removed unused `Handlebars.registerHelper` `inverse` parameter
- `each` helper requires iterator parameter


## v2.0.0-alpha.4 - May 19th, 2014
- Expose setup wrappers for compiled templates - 3638874


## v2.0.0-alpha.3 - May 19th, 2014
- [#797](wycats/handlebars.js#797) - Pass full helper ID to helperMissing when options are provided ([@tomdale](
- [#793](wycats/handlebars.js#793) - Ensure isHelper is coerced to a boolean ([@mmun](
- Refactor template init logic - 085e5e1


## v2.0.0-alpha.2 - March 6th, 2014
- [#756](wycats/handlebars.js#756) - fix bug in IE<=8 (no Array::map), closes #751 ([@jenseng](
- [#749](wycats/handlebars.js#749) - properly handle multiple subexpressions in the same hash, fixes #748 ([@jenseng](
- [#743](wycats/handlebars.js#743) - subexpression confusion/problem? ([@waynedpj](
- [#746](wycats/handlebars.js#746) - [CLI] support `handlebars --version` ([@apfelbox](
- [#747](wycats/handlebars.js#747) - updated grunt-saucelabs, failing tests revealed ([@Jonahss](
- Make JSON a requirement for the compiler. - 058c0fb
- Temporarily kill the AWS publish CI step - 8347ee2

Compatibility notes:
- A JSON polyfill is required to run the compiler under IE8 and below. It's recommended that the precompiler be used in lieu of running the compiler on these legacy environments.


## v2.0.0-alpha.1 - February 10th, 2014
- [#182](wycats/handlebars.js#182) - Allow passing hash parameters to partials ([@kpdecker](
- [#392](wycats/handlebars.js#392) - Access to root context in partials and helpers ([@kpdecker](
- [#472](wycats/handlebars.js#472) - Helpers cannot have decimal parameters ([@kayleg](
- [#569](wycats/handlebars.js#569) - Unable to lookup array values using @index ([@kpdecker](
- [#491](wycats/handlebars.js#491) - For nested helpers: get the @ variables of the outer helper from the inner one ([@kpdecker](
- [#669](wycats/handlebars.js#669) - Ability to unregister a helper ([@dbachrach](
- [#730](wycats/handlebars.js#730) - Raw block helpers ([@kpdecker](
- [#634](wycats/handlebars.js#634) - It would be great to have the helper name passed to `blockHelperMissing` ([@kpdecker](
- [#729](wycats/handlebars.js#729) - Convert template spec to object literal ([@kpdecker](

- [#658](wycats/handlebars.js#658) - Depthed helpers do not work after an upgrade from 1.0.0 ([@xibxor](
- [#671](wycats/handlebars.js#671) - Crashes on no-parameter {{#each}} ([@stepancheg](
- [#689](wycats/handlebars.js#689) - broken template precompilation ([@AAS](
- [#698](wycats/handlebars.js#698) - Fix parser generation under windows ([@osiris43](
- [#699](wycats/handlebars.js#699) - @DATA not compiles to invalid JS in stringParams mode ([@kpdecker](
- [#705](wycats/handlebars.js#705) - 1.3.0 can not be wrapped in an IIFE ([@craigteegarden](
- [#706](wycats/handlebars.js#706) - README: Use with helper instead of relying on blockHelperMissing ([@scottgonzalez](

- [#700](wycats/handlebars.js#700) - Remove redundant conditions ([@blakeembrey](
- [#704](wycats/handlebars.js#704) - JavaScript Compiler Cleanup ([@blakeembrey](

Compatibility notes:
- `helperMissing` helper no longer has the indexed name argument. Helper name is now available via ``.
- Precompiler output has changed, which breaks compatibility with prior versions of the runtime and precompiled output.
- `JavaScriptCompiler.compilerInfo` now returns generic objects rather than javascript source.
- AST changes
  - Additional PartialNode hash parameter
  - New RawBlockNode type
- Data frames now have a `_parent` field. This is internal but is enumerable for performance/compatability reasons.


## v1.3.0 - January 1st, 2014
- [#690](wycats/handlebars.js#690) - Added support for subexpressions ([@machty](
- [#696](wycats/handlebars.js#696) - Fix for reserved keyword "default" ([@nateirwin](
- [#692](wycats/handlebars.js#692) - add line numbers to nodes when parsing ([@fivetanley](
- [#695](wycats/handlebars.js#695) - Pull options out from param setup to allow easier extension ([@blakeembrey](
- [#694](wycats/handlebars.js#694) - Make the environment reusable ([@blakeembrey](
- [#636](wycats/handlebars.js#636) - Print line and column of errors ([@sgronblo](
- Use literal for data lookup - c1a93d3
- Add stack handling sanity checks - cd885bf
- Fix stack id "leak" on replaceStack - ddfe457
- Fix incorrect stack pop when replacing literals - f4d337d


## v1.2.1 - December 26th, 2013
- [#684](wycats/handlebars.js#684) - Allow any number of trailing characters for valid JavaScript variable ([@blakeembrey](
- [#686](wycats/handlebars.js#686) - Falsy AMD module names in version 1.2.0 ([@kpdecker](


## v1.2.0 - December 23rd, 2013
- [#675](wycats/handlebars.js#675) - Cannot compile empty template for partial ([@erwinw](
- [#677](wycats/handlebars.js#677) - Triple brace statements fail under IE ([@hamzaCM](
- [#655](wycats/handlebars.js#655) - Loading Handlebars using bower ([@niki4810](
- [#657](wycats/handlebars.js#657) - Fixes issue where cli compiles non handlebars templates ([@chrishoage](
- [#681](wycats/handlebars.js#681) - Adds in-browser testing and Saucelabs CI ([@kpdecker](
- [#661](wycats/handlebars.js#661) - Add @first and @index to #each object iteration ([@cgp](
- [#650](wycats/handlebars.js#650) - Handlebars is MIT-licensed ([@thomasboyt](
- [#641](wycats/handlebars.js#641) - Document ember testing process ([@kpdecker](
- [#662](wycats/handlebars.js#662) - handlebars-source 1.1.2 is missing from RubyGems.
- [#656](wycats/handlebars.js#656) - Expose COMPILER_REVISION checks as a hook ([@machty](
- [#668](wycats/handlebars.js#668) - Consider publishing handlebars-runtime as a separate module on npm ([@dlmanning](
- [#679](wycats/handlebars.js#679) - Unable to override invokePartial ([@mattbrailsford](
- [#646](wycats/handlebars.js#646) - Fix "\\{{" immediately following "\{{" ([@dmarcotte](
- Allow extend to work with non-prototyped objects - eb53f2e
- Add JavascriptCompiler public API tests - 1a751b2
- Add AST test coverage for more complex paths - ddea5be
- Fix handling of boolean escape in MustacheNode - b4968bb

Compatibility notes:
- `@index` and `@first` are now supported for `each` iteration on objects
- `Handlebars.VM.checkRevision` and `Handlebars.JavaScriptCompiler.prototype.compilerInfo` now available to modify the version checking behavior.
- Browserify users may link to the runtime library via `require('handlebars/runtime')`


## v1.1.2 - November 5th, 2013

- [#645](wycats/handlebars.js#645) - 1.1.1 fails under IE8 ([@kpdecker](
- [#644](wycats/handlebars.js#644) - Using precompiled templates (AMD mode) with handlebars.runtime 1.1.1 ([@fddima](

- Add simple binary utility tests - 96a45a4
- Fix empty string compilation - eea708a


## v1.1.1 - November 4th, 2013

- [#642](wycats/handlebars.js#642) - handlebars 1.1.0 are broken with nodejs

- Fix release notes link - 17ba258


## v1.1.0 - November 3rd, 2013

- [#628](wycats/handlebars.js#628) - Convert code to ES6 modules ([@kpdecker](
- [#336](wycats/handlebars.js#336) - Add whitespace control syntax ([@kpdecker](
- [#535](wycats/handlebars.js#535) - Fix for probable JIT error under Safari ([@sorentwo](
- [#483](wycats/handlebars.js#483) - Add first and last @ vars to each helper ([@denniskuczynski](
- [#557](wycats/handlebars.js#557) - `\\{{foo}}` escaping only works in some situations ([@dmarcotte](
- [#552](wycats/handlebars.js#552) - Added BOM removal flag. ([@blessenm](
- [#543](wycats/handlebars.js#543) - publish passing master builds to s3 ([@fivetanley](

- [#608](wycats/handlebars.js#608) - Add `includeZero` flag to `if` conditional
- [#498](wycats/handlebars.js#498) - `Handlebars.compile` fails on empty string although a single blank works fine
- [#599](wycats/handlebars.js#599) - lambda helpers only receive options if used with arguments
- [#592](wycats/handlebars.js#592) - Optimize array and subprogram performance
- [#571](wycats/handlebars.js#571) - uglify upgrade breaks compatibility with older versions of node
- [#587](wycats/handlebars.js#587) - Partial inside partial breaks?

Compatibility notes:
- The project now includes separate artifacts for AMD, CommonJS, and global objects.
  - AMD: Users may load the bundled `handlebars.amd.js` or `handlebars.runtime.amd.js` files or load individual modules directly. AMD users should also note that the handlebars object is exposed via the `default` field on the imported object. This [gist]( provides some discussion of possible compatibility shims.
  - CommonJS/Node: Node loading occurs as normal via `require`
  - Globals: The `handlebars.js` and `handlebars.runtime.js` files should behave in the same manner as the v1.0.12 / 1.0.0 release.
- Build artifacts have been removed from the repository. [npm][npm], [components/handlebars.js][components], [cdnjs][cdnjs], or the [builds page][builds-page] should now be used as the source of built artifacts.
- Context-stored helpers are now always passed the `options` hash. Previously no-argument helpers did not have this argument.


## v1.0.12 / 1.0.0 - May 31 2013

- [#515](wycats/handlebars.js#515) - Add node require extensions support ([@jjclark1982](
- [#517](wycats/handlebars.js#517) - Fix amd precompiler output with directories ([@blessenm](
- [#433](wycats/handlebars.js#433) - Add support for unicode ids
- [#469](wycats/handlebars.js#469) - Add support for `?` in ids
- [#534](wycats/handlebars.js#534) - Protect from object prototype modifications
- [#519](wycats/handlebars.js#519) - Fix partials with . name ([@jamesgorrie](
- [#519](wycats/handlebars.js#519) - Allow ID or strings in partial names
- [#437](wycats/handlebars.js#437) - Require matching brace counts in escaped expressions
- Merge passed partials and helpers with global namespace values
- Add support for complex ids in @data references
- Docs updates

Compatibility notes:
- The parser is now stricter on `{{{`, requiring that the end token be `}}}`. Templates that do not
  follow this convention should add the additional brace value.
- Code that relies on global the namespace being muted when custom helpers or partials are passed will need to explicitly pass an `undefined` value for any helpers that should not be available.
- The compiler version has changed. Precompiled templates with 1.0.12 or higher must use the 1.0.0 or higher runtime.


## v1.0.11 / 1.0.0-rc4 - May 13 2013

- [#458](wycats/handlebars.js#458) - Fix `./foo` syntax ([@jpfiset](
- [#460](wycats/handlebars.js#460) - Allow `:` in unescaped identifers ([@jpfiset](
- [#471](wycats/handlebars.js#471) - Create release notes (These!)
- [#456](wycats/handlebars.js#456) - Allow escaping of `\\`
- [#211](wycats/handlebars.js#211) - Fix exception in `escapeExpression`
- [#375](wycats/handlebars.js#375) - Escape unicode newlines
- [#461](wycats/handlebars.js#461) - Do not fail when compiling `""`
- [#302](wycats/handlebars.js#302) - Fix sanity check in knownHelpersOnly mode
- [#369](wycats/handlebars.js#369) - Allow registration of multiple helpers and partial by passing definition object
- Add bower package declaration ([@DevinClark](
- Add NuSpec package declaration ([@MikeMayer](
- Handle empty context in `with` ([@thejohnfreeman](
- Support custom template extensions in CLI ([@matteoagosti](
- Fix Rhino support ([@broady](
- Include contexts in string mode ([@leshill](
- Return precompiled scripts when compiling to AMD ([@JamesMaroney](
- Docs updates ([@iangreenleaf](, [@gilesbowkett](, [@utkarsh2012](
- Fix `toString` handling under IE and browserify ([@tommydudebreaux](
- Add program metadata
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment