Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide default for defaultLayout #249

Merged
merged 7 commits into from
May 14, 2019
Merged

Provide default for defaultLayout #249

merged 7 commits into from
May 14, 2019

Conversation

jfbrennan
Copy link
Contributor

@jfbrennan jfbrennan commented Apr 13, 2019

It pains me to see this:

app.engine('handlebars', exphbs({defaultLayout: 'main'}));

This PR makes express-handlebars default to main if defaultLayout is not set. That way you can do:

app.engine('handlebars', exphbs());

@UziTech
Copy link

UziTech commented Apr 13, 2019

shouldn't the default be 'main'?

@jfbrennan
Copy link
Contributor Author

jfbrennan commented Apr 27, 2019

We can name it whatever, happy to go with main if that’ll get this PR merged

@jfbrennan
Copy link
Contributor Author

@ericf any objections to this PR?

@UziTech
Copy link

UziTech commented Apr 29, 2019

/cc @sahat

@jfbrennan
Copy link
Contributor Author

@UziTech @ericf @sahat can I get a review? This is a simple backwards-compatible change that completes the "sensible defaults" story for express-handlebars.

@jfbrennan
Copy link
Contributor Author

Thanks @UziTech when do you expect the next release to happen?

@UziTech
Copy link

UziTech commented May 14, 2019

I don't have the ability to merge pull requests and it looks like @ericf has stepped away from the project. So @sahat is the only active contributor with the ability to merge PRs and release new versions.

@jfbrennan
Copy link
Contributor Author

@UziTech @sahat now that this suggestion has been approved I updated the docs to reflect the change.

@sahat
Copy link
Collaborator

sahat commented May 14, 2019

Sorry for the late reply, the change looks good to me, I am going to go ahead and merge it.

@sahat sahat merged commit eac8710 into ericf:master May 14, 2019
@sahat
Copy link
Collaborator

sahat commented May 14, 2019

You can find the latest express-handlebars v3.1.0 on npm, which includes this change, as well as the updated handlebars v4.1.2 dependency.

@calebolin
Copy link

This wasn't backwards-compatible. 😢

@jfbrennan
Copy link
Contributor Author

@calebolin how so?

Previously you had to exphbs({defaultLayout: 'filename'}) and you can continue to do that with the new version. If you exphbs() that works now as well with defaultLayout defaulting to 'main'

@UziTech
Copy link

UziTech commented Jun 4, 2019

express-handlebars could be used without a layout when using exphbs() which has to be changed to exphbs({defaultLayout: null}) with this change.

This should bump the major version #253

@calebolin
Copy link

@jfbrennan exactly what @UziTech said

@jfbrennan
Copy link
Contributor Author

No layout at all...never had that use case 🤔

@calebolin
Copy link

IMHO it doesn't matter whether a use case can be imagined. If the API supports it, and a release breaks that API, it should be a major version bump.

@smebberson
Copy link

Yes, this should have been a major version bump.

@guanzo
Copy link

guanzo commented Jun 12, 2019

Broke for me too

@donmccurdy
Copy link

This PR broke an example application I provide to other developers, and I've received complaints from those developers. Code that previously worked without a layout now throws an error, without intentionally updating this dependency:

Error: ENOENT: no such file or directory, open '<project-path>/views/layouts/main.hbs'

Please consider reverting the change in the 3.x lifecycle and re-releasing it in a 4.x release, although that's yet another API-breaking change so I could see the argument for leaving this alone now that it's done. See https://semver.org/. Thanks!

@twbartel
Copy link

I have the same issue that @donmccurdy has, and that is currently causing me a lot of unnecessary work. Therefore, I support his request.

@jfbrennan
Copy link
Contributor Author

For those who were broken does @UziTech's defaultLayout: null not resolve your issues?

I think the change is a positive one, but could have done my part to help the maintainers identify non-backwards compatible use cases.

@twbartel
Copy link

@jfbrennan Yes, it does resolve the issue. Of course, the code to adapt is fairly minimal and takes only 5 minutes. What was quite a bit of work, in my case, was:

  • Figuring out what my clients complained about
  • Figuring out why that happens, and which npm package to focus on
  • Finding this discussion and understanding the issue
  • Deciding on a way forward (pin version to 3.0 or go with 3.1 or something else?)
  • Making a change to a training video
  • Communicating the change

All in all, I estimate I lost 4-5 hours due to this change. I was rather unhappy with this, because it produced no value for anybody.

@kevfromireland
Copy link

Just encountered this breaking change today myself.

FWIW, I really appreciate the effort you put into the library and the hassle it has saved me. The value it has provided me over the past year of using it nicely balances out the few hours today I had to burn :)

@PaulBehrendtVentoro
Copy link

hit us too, why still no 3.1.1? release this as v4

@kylepeeler
Copy link

This should have been a major version bump, breaking change... follow sem-ver...

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

Successfully merging this pull request may close these issues.