Skip to content
This repository was archived by the owner on Dec 10, 2019. It is now read-only.

Expected _00-head.mustache #10

Closed
freshdevelop opened this issue Oct 4, 2017 · 12 comments
Closed

Expected _00-head.mustache #10

freshdevelop opened this issue Oct 4, 2017 · 12 comments
Assignees

Comments

@freshdevelop
Copy link

I am using Pattern Lab Node v2.12.0 on Windows, using the gulp configuration with patternengine-node-handlebars v1.3.0.

I need to use handlebars conditional tags for selecting some scripts and styles straight into the templates .

Expected Behavior

I expected to use almost seamlessy both mustache and hbs templates for _meta files, or at least to switch from the default mustache behavior to handlebars.

Actual Behavior

Console returns WARNING: Could not find the user-editable header template, currently configured to be at source/_meta/_00-head.mustache. Your configured path may be incorrect (check paths.source.meta in your config file), the file may have been deleted, or it may have been left in the wrong place during a migration or update.

Basically I get the same issue listed and fixed here, but my meta files appear to be in place and correctly named.

Steps to reproduce
  1. Fresh prebuilt install of edition-node-gulp.
  2. npm install patternengine-node-handlebars
  3. Set "debug": true in patternlab-config.json
  4. Change _meta/_00-head.mustache to _00-head.hbs and _01-foot.mustache to _01-foot.hbs.
  5. gulp patternlab:serve

When I call gulp patternlab:help I get both handlebars and mustache as loaded and "good to go". I tried to change paths.patternExtension in patternlab-config.json to "hbs" but nothing changed.

@bmuenzenmeyer
Copy link
Member

Hey @freshdevelop

Thanks so much for the thorough report. You are right. What you report will luckily be addressed once pattern-lab/patternlab-node#611 ships. Stay tuned!

@freshdevelop
Copy link
Author

So it's normal by now that if I manually rename my head and foot file extensions to be .hbs (or if I substitute them with the ones in this repo) it won't work. Can you confirm, please?

@Josh68
Copy link

Josh68 commented Mar 28, 2018

These commits are in @pattern-lab/patternengine-node-handlebars, v2.0.0-alpha.1 (now 2). I'm going to try using with PL 2.12.0, but not sure it will work. Will report back. Was there an intent to backport this fix to a patternengine-node-handlebars v1.0.4? @freshdevelop, the current version of the non-scoped package is 1.0.3, not 1.3.0.

@Josh68
Copy link

Josh68 commented Mar 28, 2018

My attempt to use the scoped package failed to resolve the issue, so I didn't even bother reverting my meta files from hbs to mustache. Is there any workaround to use hbs meta files with the old patternengine-node-handlebars? PR for the old version to merge those fixes from the new scoped package?

@bmuenzenmeyer bmuenzenmeyer self-assigned this Mar 28, 2018
@bmuenzenmeyer
Copy link
Member

bmuenzenmeyer commented Mar 28, 2018

im a bit hurried right now, but let me dig into this and see what we can do. I have tried not to look backward too much as development rolls on (a matter of bandwidth), but let's see if there is an easy fix.

@Josh68
Copy link

Josh68 commented Mar 28, 2018

Thanks, @bmuenzenmeyer. I tried mucking with my own setup locally and realized this is a sticky wicket. I actually had the patternengine-node-handlebars but not the styleguidekit-handlebars-default installed. When I installed the handlebars styleguidekit and tried removing the mustache kit, then modified patternlab.js and patternlab-config.json to try to use the handlebars kit and the desired extension in my config, things blew up.

I'm using the Webpack edition, which (like most or all, I think) is based on the mustache kit and may have mustache rendering calls pretty deep down. It doesn't seem like the kit modifies the patternlabFiles entry in patternlab-config.json, either, so the kits aren't exactly setting up core to manage the SG templates according to user-specification. Maybe this is too difficult to backport, but thanks for looking.

May be time to help the team managing the Webpack edition upgrade to 3.0, which is on their agenda. I have a somewhat working setup with PL3 and Webpack 4 in a separate repo.

@Josh68
Copy link

Josh68 commented Mar 29, 2018

One related question. When using PL v2, I assume that all of my packages should be un-scoped (not @pattern-lab/package). I've been noticing that when I pull up un-scoped versions in npmjs.com, the links to github repos are to the scoped packages, which I thought were all specific to PL v3. Thanks

@bmuenzenmeyer
Copy link
Member

When using PL v2, I assume that all of my packages should be un-scoped (not @pattern-lab/package). I've been noticing that when I pull up un-scoped versions in npmjs.com, the links to github repos are to the scoped packages, which I thought were all specific to PL v3.

I think that's generally true... you can see the first core package on npm was a 3.0.0 alpha - so I'd be curious to know where you found that.

When I installed the handlebars styleguidekit

If you are referring to this package it's not one managed by the team - though this name looks familiar to me.

The UI using Mustache to compile templates is separate from core using Mustache to compile patterns. They don't cross streams, making Mustache for UI and Handlebars for Patterns (and head/foot, what this issue is about) possible.

I know there are a lot of moving parts and churn on my part that is contributing to this, but I'd love it if we could focus efforts forward together.

If you want to monkey patch this however, see https://github.com/pattern-lab/patternlab-node/blob/8748417979a9f810975fffabffe011552d08d2f1/core/lib/patternlab.js#L294 and https://github.com/pattern-lab/patternlab-node/blob/v2.12.0/core/lib/patternlab.js#L314 which have the hardcoded extensions.

@Josh68
Copy link

Josh68 commented Mar 29, 2018

I think that's generally true... you can see the first core package on npm was a 3.0.0 alpha - so I'd be curious to know where you found that.

Sorry for the confusion ... in this case, I was talking about the patternengine for handlebars. Old JS core has the same issue - Github link to new core.

I did figure out, of course, that the engine and kits manage completely different things, which is how I ended up finding this issue. And I did see that the old kit is 1) Not by the core team and 2) documented only for the PHP version. Hence, it didn't work.

Ultimately, I managed to do what I needed to do (insert fontawesome CSS in the head using a custom helper) by hacking mustache with a global helper and using the plugin-node-engine-extender (thanks to Rob Waymouth) to create both a handlebars helper for icons within my patterns and the mustache "helper" to get the styles in the head.mustache.

Finally, I did try monkey-patching patternlab.js, but I guess I'd have to try with the @pattern-lab scoped styleguidekit, and I don't think it will work with PL Node v2. As it is, I have a working solution until I can upgrade to v3.

I guess what I'll want to find out, when I do upgrade, is whether installing a styleguidekit actually updates your config (e.g., to point to and correctly render PL templates of the right type), and how it handles even installing multiple kits. With v2 core and associated kits and engines, it seems like I can throw whatever I want at it and make a mess of things. I don't think there's an automated way to avoid that, and I guess it's the price of having choices ;)

@bmuenzenmeyer
Copy link
Member

using the plugin-node-engine-extender

i've never seen this! the community continues to astound me. glad you found a working solution - don't be a stranger as you continue to use PL

@Josh68
Copy link

Josh68 commented Apr 1, 2018

Turns out this plugin has obliterated the effects of plugin-node-tab, so I have more debugging to do to come up with a satisfactory solution. There's no way to manage the order of plugins loading, is there? Thanks

@bmuenzenmeyer
Copy link
Member

There's no way to manage the order of plugins loading, is there?

currently, no, but we could perhaps add an order property or explicitly iterate through them in the order supplied within patternlab-config.json ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants