Figure out multiple configs passed to compiler about haul HOT 14 CLOSED

I'll see if I can squeeze some time to look into the source code, got a ton of work ahead of me, sadly. Maybe @TheLarkInn has some immediate feedback, but I need to see the source code myself before coming up with a fix. One thing you mentioned was that it builds all configs at once. One thing I've seen is that you can use webpack-merge to generate a config, that could be of use for the async functionality or even switch between ios and android builds. If webpack compiles regardless of changes, we've got a thread on webpack-cli on how to avoid this. Hope it helps!

from haul.

I've got some time in 2-3 weeks, got a hectic period of exams right now. If ok, can look into it then 👍

from haul.

Update: new solution is to require --platform flag with either ios, android or all value. When all is set, Webpack enters multi-compiler setup and will serve both platforms.

Ultimately we want to do all always as long as we can provide a satisfactory performance. Upgrade path would be to make platform no longer required and by default, build for all.

from haul.

I'll continue working on that tomorrow. Now moving to other things.

from haul.

Note for tomorrow: we have to remove progressBar plugin from webpack config and attach it manually to the multi-compiler. That way, we can manually create n progress bars that work together.

Currently progress bars are causing glitches as each compiler tries to override the same bar with its progress.

I have it working on my draft branch, need to cherry-pick it.

A nice benefit of that addition is that it nicely illustrates serial nature of webpack compiler.

from haul.

I don't think there is a option to fix/make workaround for rebuilding iso and android bundle source files changed, since webpack treats it separatly, so ios compiler this that source code has changed for this bundle, and android compiler also. However if we rewrite dev middleware maybe we can implement solution that will lazily build bundle that is requested and watch it, but not build the other one, but if the other one is requested we stop watching the first one, builds the second and watch it or something similar.

from haul.

Also, is something blocking us from having 2 parallel builds in separate threads?

from haul.

If I understood this correctly, you want to build recursively and async, not all at once? @grabbou

from haul.

Yup, @ev1stensberg + first build lazy (on request for entry point).

from haul.

Just wondering if you had any time to look into this recently. Not a top priority but worth keeping in mind as far as planning goes.

from haul.

Sounds good, let me know and I'll be happy to pair on implementing/discussing that

from haul.

Just need an email / open DM on Twitter ✌️

from haul.

@jukben @satya164 is this still relevant on next branch?

from haul.

No longer relevant.

from haul.