Support HTML injections / license comment

jaketrent / html-webpack-template

a better default template for html-webpack-plugin

MIT License

830 stars 139 forks source link

Support HTML injections / license comment #51

Closed AndersDJohnson closed 6 years ago

AndersDJohnson commented 7 years ago

Support an option accepting a string to be injected as a comment to specify license. Or alternatively, any custom HTML to be injected at the top or bottom of the document, or further of the body or head elements.

holyfirexx commented 6 years ago

I'd like this functionality as well. This plugin completely removes the need for my project to use a template file except for a throbber that is shown while the app is loading.

If there was an option to inject html I could just do that instead of having to have a separate file for ~1 line of html.

holyfirexx commented 6 years ago

I created a pull request for this. #62

jaketrent commented 6 years ago

@holyfirexx thanks for the PR. cc @AndersDJohnson

A couple things:

Thanks for your patience. I haven't gotten to this quickly.
The API for this library is expanding where it's almost harder to use than just creating an html file. Why would someone come use this library these days? What do you all think?
Related, said another way, once you can inject a string of HTML, why not just write html instead of html in a string in json?

I'm interested on your takes on these questions. I'll likely merge the PR. But if I was to give this package serious love later on, I'd probably widdle down the API to the most general use case that would allow the wide range of things that people are trying to do. But that's probably html string injection (what's more general, right?). And in that case, I wonder strongly at the value of the package. Thanks for your feedback.

holyfirexx commented 6 years ago

Hey @jaketrent,

It probably comes down to personal preference. Yes, I could just write an HTML file myself, but this plugin removes a lot of boiler plate. Also, what if I want to have different files for test, dev, prod? I could just create a single file with the config for this plugin and then override individual settings as needed for each environment instead of creating 3 different templates for each.

Personally, I think each addition to the API should be analyzed individually. Does a feature merit a user having to create a separate template? If a feature is so out of scope that they should just create a template then it doesn't belong in the API. But if, for example, adding a single line of HTML doesn't merit having to create a template, then why wouldn't it be added? Then the decision about when to move from this plugin to a template is the users.

jaketrent commented 6 years ago

@holyfirexx Thanks for your thoughts. I like the specific use case of environment overrides per attribute. Thanks for that.

I think I'm just going to merge your PR for now. We'll see what the future holds in terms of holistic api design.

Thanks for your help.

holyfirexx commented 6 years ago

Thanks! Not a problem, glad I could contribute.

AndersDJohnson commented 6 years ago

Resolved by #62.