trying to migrate to DOM parser

[sudo-vaibhav]

Trying to add DOMParser so that we could target injection using CSS selectors

[colbyfayock]

i think it's working okay, i dont think you need the decoding there

the reason i had things like:

<h1>Hello world!</h1>

was because I was having an issue getting those to run through the compile steps and output in a way that would still work in the browser as text

it looks like jsdom serializes the output a little differently than it did before, which is okay, but that means the tests will break

i would recommend checking all of the tests and seeing what the differences are, opening the compiled files locally in your browser, and make sure that they work

you can test the compilation works for the files by navigating to the example directory, the nrun:

../../node_modules/webpack-cli/bin/cli.js --config webpack.config.js

That will run the webpack compile steps, and output in the dist folder of that example

What i've been doing is copying the output files from dist/ into fixtures, so for instance, examples/basic/dist/index.html is basic.html

could you revert some of the changes like the single quotes? id prefer to keep those as i originally had and remain consistent with the rest of the respository

overall though this is looking great - nice work getting this together, think we can keep moving on it

[colbyfayock]

once you get those tests fixed up we can walk through making a new test using CSS selectors :)

[sudo-vaibhav]

That change of quote signs is probably because of some vs code extension or beautifier I'm using. I think its because of prettier which keeps formatting the document. It keeps changing back to the prettier formatting on every save. Is there some config file for your formatter that I can enable or use to ensure a consistent code formatting style?

[sudo-vaibhav]

The partial injection works now. Now the location property works with CSS selectors just like any HTML tag. And since every HTML tag is implicity a CSS selector anyways, this is backwards compatible. Updating tests and docs needs to be done though.

[colbyfayock]

awesome job with all of this 💪 i think we just need to fix the meta tag placement so that we don't inadvertently cause any issues with how the page loads for people

[sudo-vaibhav]

Sorry, I am slightly busy this week. So the time I can devote is slightly reduced. I already have a solution to the meta tag problem in mind. I just have to Implement it. The idea is that whenever we get a head tag with high priority, I will try to programmatically insert it after the last meta tag.

Also, It will be great if instead of just giving high and low priority options, we just give the 4 options that are there in insertAdjacentHTML by default, namly - "beforeend, afterbegin", "afterend" and "beforebegin".

[colbyfayock]

now worries! there's no rush :) i appreciate you doing this

That's interesting - i think i'd be more inclined to suggest that we can add those but keep the originals available, that way it's not a breaking change for people who are already using the high and low priority

you can create an object map, so that we can maintain the original keys but map them to the right API definition

const map = {
  high: 'afterbegin',
  low: 'beforeend'
}

if ( map[priority] ) ...

[sudo-vaibhav]

I also have a question now that I have wandered around trying to solve the problems of adding partials into our webpages in my workplace. EJS seems a worthy solution to the partials injection problem, it works just fine. This brings in a question. Why do we need this plugin? Is there something I am missing here? Why would someone want to go for this plugin instead of using EJS templating which can inject partials and I think also do crazy stuff like looping and adding code dynamically?

[colbyfayock]

im not familiar with EJS - but the idea is HTML Webpack Plugin is a popular way to build out sites with Webpack. This extends it making it easier to manage small snippets of code throughout the generated HTML, rather than having to manage the index.html file as a template

i dont think this is really doing anything crazy

[colbyfayock]

if you dont have any interest in continuing on this - i could branch off of your work and wrap it up. i appreciate what you did either way :)

[sudo-vaibhav]

Don't worry, I'll keep working on this. Its just that right now, the code at my place is turning into a weird sphagetti of ejs partials and html partials due to the lack of precision in injection in this plugin. I am using ejs wherever this plugin doesn't fulfill our needs. And also one weird thing , Even with the new code I wrote, the injection doesn't work when I test it in my workplace project. Even though examples work fine in the plugin , in the real projects, whatever I wrote is not working and I can't figure out why and this is frustrating me. I agree that the meta tag part is not finished in that code but that shouldn't matter in my use case as I am not injecting anything in head anyway. I'm confused why my new code addition to this plugin doesn't work in production if it works on the examples, in my workplace project code, the plugin behaves as if it isn't even there. No injections happen. I'm confused 🤔

[colbyfayock]

do you see any errors in the terminal? or maybe are you on an older version of webpack?

[sudo-vaibhav]

Also could the failure to inject partials in my work project code be happening because I'm always giving multiple target html files to insert into? Like in all the examples, either we dont specify a base index.html at all or if we do, its just one file. But in my project, I'm always passing an array of multiple files which is cool according to the docs and also works on older versions of this plugin. Did I break something? Can we make an example for multiple files being targeted by the same partial?

[sudo-vaibhav]

I am doing crazy partial injection in the real project which is much more complex than the examples, I'll try to show it to you in a gist. Its real bonkers. I'm putting multiple partials in one file and also putting the same partial in multiple files.

[sudo-vaibhav]

could you maybe point me to the part of the code which handles what happens if the same partial gets multiple files to target? or is it something that's handled by some webpack thingy outside of our control?

[sudo-vaibhav]

Here is a gist of my webpack config: https://gist.github.com/sudo-vaibhav/836e19d6a4f747a7a483d4804819743a And my new code is not working at all for this config... Tell me if that's not the most insane use for your plugin you have ever seen 😄

[colbyfayock]

haha ill definitely say it's an impressive use!

I'm totally up for you creating any sort of example that helps. for that - i would actually recommend creating a separate branch, then create the example there, which we can merge in with a different pull request

once that's working with the original plugin code with passing tests, you can merge that branch into this branch, where we might be able to see where it's failing

does that make sense?

as for the injecting to multiple templates - here's the code: https://github.com/colbyfayock/html-webpack-partials-plugin/blob/061c1eb3877e1fa77a7404512bef2db9bd54d3ab/index.js#L29

template_filename isn't actually utilized to perform an action, rather it's used to identify the template that this plugin should inject to

the logic in that file should probably be simplified a bit to make it more readable, as it's kinda hard to read in that big return statement

so for example, in this example: https://github.com/colbyfayock/html-webpack-partials-plugin/blob/688d8e0ff372979881dc2f34266dbf3aee6bc891/examples/page-template/webpack.config.js

in the HTMLWebpackPlugin configuration, we have a template that we're defining as about.html. in one of the instances of HTMLWebpackPartialsPlugin, we're telling the plugin that we want to target that about.html template

[colbyfayock]

hey @sudo-vaibhav i know its been a little while, but do you still wanna wrap this up? some good work in here! and i think some others would love the feature too

[colbyfayock]

closing this for now - feel free to reopen if you come back to it and catch the branch up