Consider removing Webpack/React option

[pydanny]

We are getting a lot of support requests for our Webpack integration. Unfortunately, it doesn't work with all setups configurations all the time. None of the core devs of this project are that knowledgable of the toolchain, and have difficulty helping users. Community assistance with the issue has also been negligible, and we're not even sure who understands the toolchain.

Please share your opinions.

Paging @goldhand, @jayfk, @luzfcb, @audreyr, @theskumar

[jayfk]

I'd love to keep support for webpack in Cookiecutter Django, but only if we find a way to provide a strong integration.

I think @GoldHands work is fantastic, but a loosely coupled integration via post_gen hook is not enough in my opinion. Supporting Webpack and React/Redux pulls in a whole eco system of stuff that needs support. To make things worse, they are constantly moving (and breaking) things.

[luzfcb]

@pydanny since I never use Webpack, and I only had time and reason to learn Webpack and ecosystem if the team that I work begin to use it (I do not see any chance of that happening in the short and medium term), I'm +1 to remove Webpack support from cookiecutter-django, except if someone takes responsibility to keep working integration with Webpack.

[goldhand]

Awww this is sad but I understand. I've been trying to keep up with any webpack related issues but I've been a bit busy adjusting to my new employer and may have missed them. I'm still maintaining hzdg's cookiecutter-webpack but I'm no longer with them so thats another thing to consider in support of removing it.

However, if there's a way to divert those support requests to cookiecutter-webpack instead of here maybe that would help?

Supporting all of cookiecutter-django's many deployment options would be difficult and too much of an undertaking for me alone. I could start working on a couple of the configurations, like heroku so that deployment works out of the box. I guess the next big issue would be getting docker working...

[pydanny]

@goldhand, diverting support requests is only going to help so much because a lot of them are environment specific. Thanks for letting us know about your work status, as it is a factor.

Here are the options I'm considering:

1. Maintain the status quo. Try to ramp up community support for the integration.
2. Add a fork or replacement of hzdg/cookiecutter-webpack to someone or some group with a vested interest in constantly maintaining it.
3. Remove direct Webpack/React integration and just specify how to integrate hzdg/cookiecutter-webpack in the docs.
4. Remove Webpack/React altogether

[goldhand]

In the event of 3. I would be happy to write/help with the docs. I think thats a good solution too.

[theskumar]

TLDR; let Frontend community do their work and we do what we are best at, use webpack-loader to provide just basic integration with the output bundle, don't get hands dirty with all the things possible with webpack/gulp/etc.

Over the time, using grunt to django-compressor to gulp, the coming of django-webpack-loader is one the best thing to happen with Django asset management. I would strongly recommend using it on a project with fair amount of Frontend work going on.

Coming back to the problem of maintainability here, I believe we don't need to maintain everything possible combination of tasks that can be done with webpack. The core problem is the integrating the Frontend build with templates rendered in django. If we just do that, no more no less, the community should be happy. Please don't add integration for react, or angular. Just basic manifest file creation with hashed filenames, which is picked up by Django. Any fronted guy should be add their own integration for sass, coffee, typescript, react, browersync, etc. The docs for doing all those are widely available.

We are working on exact this kind of integration in this PR[1] and it is expected to evolve over the time as we use it on more and more projects.

My 2 cents!

[1] Fueled/django-init#184

[Afrowave]

Thank you very much guys, for all the hard work.

As a Frontend web dev, I must say I have followed the grunt/gulp/webpack journey, not forgetting the shift to ES6. Frontend has become a "monster" in itself. To help me keep my Frontend and Backend concerns separated, I use CodeKit and there is an upgrade in the works - CokeKit 3.. FYI, the integration with Sublime Text is excellent.

So for those in my position, it makes sense to go with option 3 or 4.

Just so you know, I hang around the shadows but I am extremely grateful for all the work.

[ssteinerx]

@Afrowave The CodeKit 3 beta announcement is not dated -- how long has it been in beta?

[Afrowave]

From Dec 2015. But if you know Bryan, this is not surprising. I am willing to wait.

[ssteinerx]

hzdg/cookiecutter-webpack is also much too heavy including react and a whole pile of other fung.

It would be better to have a very minimal webpack setup rather than trying to be all things to all people.

I, for one, don't need the overhead of React in every application if I'm not even going to use it. If I need it, I'll add it and somebody who doesn't know enough to do that is not going to be able to use it anyway!

OTOH, not having webpack at all would be very sad.

@pydanny Would you accept a pull request for a minimalist approach for now, to which we could easily add later?

[pydanny]

@ssteinerx I'm very interested in a pull request for a minimalist approach for React. 👍

In general that's the approach we like, because it's easier to maintain and allows individual project creators a foundation, not a whole framework.

[ssteinerx]

I'm not talking about React, I'm just talking about a minimal functioning webpack setup! Right now, out of the box, it doesn't work at all.

[theskumar]

On Sep 6, 2016 11:12 PM, "Daniel Roy Greenfeld" notifications@github.com
wrote:

@ssteinerx I'm very interested in a pull request for a minimalist
approach for React. 👍

Curious why react and why not just web pack for standard front-end build
with revisions, minification, etc.

Someone would might like to angular or any other framework.

In general that's the approach we like, because it's easier to maintain
and allows individual project creators a foundation, not a whole framework.

+1

[pydanny]

@ssteinerx, I meant Webpack, not React. 😄

[jayfk]

It's not so much about just adding webpack, it's about supporting it over time.

[ssteinerx]

@jayfk At the moment, it's not at all functional. It's one thing to support a simple bundling of files and making it simple to add others. It's another thing entirely to support React within Django. I don't believe that's within scope in this project -- there's so much more to it that it's worth a tutorial blog post, but I don't think it should be included as part of this project. Having just migrated a project just between minor React versions, there's no way we could keep up here. Leave it to the user to add if they want it and want to maintain it for their project.

[ssteinerx]

Also, I think maintaining dependencies with Bower is much easier and way easier to understand.

[jayfk]

@ssteinerx you won't hear any counter arguments from me, as I'm completely on your side.

My only concern is that we need to provide ongoing support for it once we include it in Cookiecutter Django.

[goldhand]

I'm in favor of a minimal webpack version. I wanted to make one on hzdg/cookiecutter-webpack without react etc but never got around to it.

I strongly disagree with using bower though. NPM hosts ~320k packages compared to bower's ~50k hosted. With ~400 new packages published daily, the gap between the two continues to widen. Even if bower is easier to understand (I disagree here too) I don't think it justifies the massive difference in community sizes.

On another note, it's probably not the best time to do a webpack pr on the eve of webpack 2. There's a big push and lots of new contributors working on it now. It might be easier to remove webpack for now and wait for webpack 2 to come out of beta before integrating it into cookiecutter-django.

Alternatively, we could make a very simplified branch of hzdg/cookiecutter-webpack and use that until webpack 2 is released.

[ssteinerx]

@jayfk -- Agreed, it has to be something we can continue to support; React ain't that at this early stage.

@goldhand -- I didn't realize the disparity was that great between Bower and NPM. Of course, a lot of what's on NPM isn't relevant in this context but I actually use them side-by-side. Not a big deal; it's a tiny bit of configuration to support both.

PROPOSAL: Let's first disentangle all webpack/React/etc. code from the master branch and move it to a separate branch. It doesn't even have to do anything (e.g. work), just let's get it unentangled from the main codebase and preserve the work that's been done so far.

I know there is a 1.9.9 -> 1.10.1 branch going, so there's going to be a bit of rebase juggling to do.

BIG QUESTION: Who knows this codebase well enough to do the "disentanglement branch"/merge to master (hint: it sure ain't me), and has the time to do it?

BIG QUESTION 2: Same as above but, once the disentanglement is complete, rebase the 1.10.1 branch so it's built on the newly purified master.

I'll be happy to work on a Webpack (2?) branch when the current codebase is cleaned up, but doing anything with it in the current starting state (with Webpack 2 around the corner as @goldhand pointed out) is a fool's errand, in my opinion.

[goldhand]

@ssteinerx Luckily all the webpack/react stuff should be easy to remove: f036ae4

The webpack-loader configuration will be useful if a webpack option is still offered at all by django-cookiecutter

[jayfk]

@ssteinerx What branch are you referring to? We are just waiting for every package to officially support Django 1.10.

I'd say: Start with the current master and revert f036ae4. You can open a WIP PR to discuss the implementation. If you need help with Docker, hit me up on gitter and I'll add it.

[ssteinerx]

@goldhand Can you do a branch where you back that out and rebase to the current master? That would be awesome! I agree that we need to add this back in when as @goldhand pointed out, we have a bit of webpack 2 stability and can spool it in one little bit at a time.

Thanks for your help!

[ssteinerx]

@jayfk -- I don't have repo access, can you make a "pull out webpack for now" branch and do as you suggested and let's see how it goes?

[ssteinerx]

Related: what is the state of #703?

Could we pull out the webpack, update to Django 1.10.1 and pop out an updated release?

That'd be awesome as all my new projects are Django 1.10 + django-channels.

[jayfk]

@ssteinerx I can't do that right now, I'm currently on mobile. Can't you just fork and open a PR?

[ssteinerx]

@jayfk So fork, revert f036ae4 and PR onto master?

I'm suggesting we do that on a new branch which I can't create.

Can you make a "un-webpack" branch (or could anyone, please?) that I can do a PR on?

[jayfk]

@ssteinerx there you go: https://github.com/pydanny/cookiecutter-django/tree/pull-out-webpack-for-now

[ssteinerx]

@jayfk On it, thanks!

[ssteinerx]

@jayfk Not familiar enough with how entangled this has become. Ha, you make joke! Thanks for the quick grooving in.

[ssteinerx]

@jayfk I think the commit number you referenced was from goldhand's repo -- it doesn't exist in this repo.

I found this one, but it's not a merge commit 8880e77

Be nice if the pull request in GitHub actually gave the commit sha of the actual merge commit -- maybe it's there somewhere but I don't see it...

I don't think I've ever reverted a merge commit before...fun, fun, fun!

[jayfk]

@ssteinerx yep

[ssteinerx]

Travis claims this is the one it tested: 1b205ea

But that one doesn't exist at all...

[ssteinerx]

Really, other than untangling the docs, removing the option for WebPack from the cookiecutter.json would effectively remove it...if there's no way to set the value, the code in post_gen_project.py will just sit there unused, not causing any troubles and there are only 11 other files the even contain grep -i webpack

[ssteinerx]

Because the addition was (thankfully!) done by cookiecuttering in the whole @goldhand project, none of the files from that repo are in here at all. Good way to do it, too much stuff at once.

[ssteinerx]

@jayfk @pydanny -- This is merged, yes? If so, please close?

[pydanny]

Closing