Added support for module name and auto-resolution of chunk name #191

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

Jump to bottom

Closed

pytrumpeter wants to merge 1 commit into django-webpack:master from pytrumpeter:master

Closed

Added support for module name and auto-resolution of chunk name #191

pytrumpeter wants to merge 1 commit into django-webpack:master from pytrumpeter:master

Conversation

@pytrumpeter

Copy link

@pytrumpeter pytrumpeter commented Feb 19, 2019 •

edited

Loading

I have multiple webpack entry points in my project, and depending on changes to JS or CSS code I made in any given module, I'd have to constantly change the bundle_name value. See issue #165. So, to prevent having to constantly make these changes, and to avoid breaking current functionality, I created a new template tag, render_bundle_auto, where you can simply use the entry point name as your bundle_name and the plugin will search for that name within the chunk names. If the module name is in a chunk name, it will include the tag. I have tested this for my own config and it's working fine, but there are very different webpack configs out there, so that's a major caveat.

Also, this code assumes that if you include a content hash in your Webpack config, that it is separated by a hyphen (seems like this is the convention?)

I'm very open to suggestions or changes.

@pytrumpeter


 Added support for module name and auto-resolution of chunk name

b1bd821

@pytrumpeter pytrumpeter mentioned this pull request

Feb 19, 2019

Code Splitting #165

Closed

@bhrutledge

Copy link

Contributor

bhrutledge commented Feb 19, 2019

Thanks for the work, @harveynr. I'm not a maintainer of this project, but I recently dug into existing issues and PRs that I believe are related to the issue you're describing. Did you take a look at PR #182? Does that address your issue at all?

Also, when submitting a PR, I think it's helpful to reference the issue(s) that you're trying to fix in the description; in this case, that's #165. GitHub will link between the issue and the PR.

@pytrumpeter

Copy link

Author

pytrumpeter commented Feb 20, 2019

I did see #182 along with one or two others, and I think it either had external dependencies that it was hung up on, and/or it had a lot more code that had changed. I ran into this issue in a big way a few days ago, and after monkey patching the code today, I figured I'd tidy it up a bit and submit it. I think ultimately someone just needs to pick the best solution, I don't know if this is it, but it was a quick (and rather dirty) fix that seemed to work. Also thanks for the reference to the issue, I referenced the PR from the issue but not the other way around.