Re.Pack - Bringing Webpack to React Native

youtube-cover
Subtitles
Show
[Music] hello everybody and welcome to another react native show episode today we are going to talk about repack and a very interesting open source library that uses webpack so we're gonna learn what this has to do with react native and why you should be probably using it today with me is a very special guest travel that works with me at call stack so papa very nice to not meet you because we know each other but i'm pleased to have you on this podcast uh so you know how about you just introduce yourself in a couple of words for those of our listeners that are here you know for the first time before we go into the repack and all the benefits that it has uh yeah uh hi mike uh thanks for having me uh i'm pavel also known as zamotani on the internet uh like like i said uh i work here at kolstek i'm a software developer for more than four years now um really excited to be here nice great i'm also really excited to have you today because we have a very special topic that uh you know is something that you've been working on for a while now so you know i know the name is repack uh what can you tell me about this project okay so repack is uh a direct successor to whole hall was also a open source project that we did here at call stack and essentially a repack is a toolkit for react native applications that works with webpack so webpack is a bundler for your uh javascript or typescript code and you use repack to make that bundle that webpack generates work with react native so while webpack is a bundler repack is a
toolkit or set of apis that allows you to use webpack for developing regnative applications it has support for features like hermes flipper or react refresh and we plan to add more features that are exclusively available in webpack which you cannot for example do in metro wow that's quite a lot of keywords in a single answer and i guess before we go into the details it would be great to talk about some basics like for example what do we need a bundler for in context of react native uh if we are actually building a mobile application yeah so when we are writing the code for the reg native we usually write it in javascript or typescript and this code is split between multiple files right your source code the consists of multiple files and you also have dependencies that lives in for example node modules uh so those files might contain a syntax that is not well understood by the javascript vm uh for example you're using arrow functions or cons on that this is the syntax that might not be uh not be supported yet in javascript vm so you have all these files that are not runnable right now and you need a way to pack them together into a single or few smaller files and transform them at the same time to something that the javascript vm understands and this is what the webpack does it takes your code it transpiles it for example with bubble and packs it together alongside minification happens to make sure that you ship the smallest possible code without any comments or additional stuff that affects the size because the less code you write the
less time spent on evaluating and processing that code yeah and i guess you know for for that reason facebook had to develop petrol i mean i guess we'll get into that a bit later but um there is already metro in react native which is kind of the default and every time you actually install a react native locally on your machine this is what you get so i guess what would be the biggest selling point of repack if i were to use it over metro so the biggest selling point of repack is that it's based on webpack repack itself is not a bundler so it's not a direct competitor to to metro but it's a set of apis that will make webpack a bundler for regulated applications so uh the the biggest selling point like i said is webpack because it's support it supports a lot of features that are not otherwise available for real native developers like you have this whole ecosystem of webpack loaders plugins and the vast amount of configuration options so the strength of of repack is that is based on the webpack essentially and the webpack has been uh in the market for years now and has a widespread adoption especially in the uh web development community yeah that that makes a lot of sense and uh you know before before doing this podcast um i also did a bit of research and um you know it turns out that there was actually an attempt to use webpack with react native early days uh just before the facebook team decided to build a packager later rephrase to metro in a separate project and i guess uh there is also an issue issue number five
uh that you know we have linked to this article so we can go and check it out but i guess the primary reason uh webpack was not used was performance and lack of support for some facebook specific things like i guess you know haste modules that some of you may not remember but they were quite popular back in the day you know back to the hall which is you know like uh predator to repack i'm just curious is that also why this project despite being i guess quite popular and conceptually offering the same thing as repack never really got to the point where you were kind of satisfied with it and had you know stable features set um and you know eventually now it is sort of discounted in favor of reebok so i'm just trying to understand what specifically led to that decision um that whole never really got into you know a stable phase yes so the main problem with hull was its architecture we designed hull to encapsulate webpack under the hood so whole had its own configuration file and we had to maintain that configuration file we had to maintain all the documentation for it uh while we still were using webpack under the hood and had to convert from our configuration file format to parts one so so that we can actually run uh and because we hit uh webpack uh behind this arcade uh the issues that people had with webpack were also our issues because they were opening uh new issues on github to our project instead of webpack while a lot of the problems that developers had were already solved and you could find
them on webpack's github so that was the one thing and another was that because of this uh maintenance overhead the the feature development velocity was low so it was difficult to develop new features and sometimes even impossible or not visible like in case of react refresh the whole architecture didn't really work in a way that would allow us to do that especially since we had to also support run bundles which complicated the whole code uh to a point that it was just not possible to to implement latest and greatest features that that metro had yeah yeah that that that makes a lot of sense and i can definitely relate that over time i've also learned that sometimes building these nice abstractions while making it easier for developers to use sometimes it's just not paying off in the long term so uh you know i'm curious what was the game changer for you that you know made building repack possible i guess you're now more like you're now satisfied with you know the way repack looks like and still it is based on web packs so what is different now about repack or webpack or your approach that makes repack such a good alternative and actually something that you believe uh is going to be working really nicely yeah so there were three things that that allowed us to to create uh repack and support all of the features that that metro has so the first one is the release of webpack five that was a game changer for us the a lot of the internal code was refactored in web.
5 which
makes it easier to understand and read
the source code which was the reason why we could create for example how the module replacement with react refresh support into repack the other thing was that instead of hiding weapon configuration we now embrace it so the developers have access and they own weapon configuration and they just use our apis like plugins to to tweak the configurations to to their needs so whenever the developer have have an issue with weapon configurations let's say some loader doesn't work as they expect or something is not transpired properly they can search directly for that issue inside webpacks github repository or somewhere on the internet on stack overflow or something the last part is that we've decided not to support uh run bundles it was our deliberate decision based on the experience we've got with hull since the support for ram bundles complicates the the code exponentially so if we were to support run bundles we probably wouldn't be able to support react refresh so we opted for the greater developer experience instead of having having to support ram bundles uh since they are not that widely used yeah and that makes a lot of sense i guess sometimes you just gotta make these decisions about that supporting everything especially when you know the future of certain features is not really settled yet and it may happen that ram bundles are not popular in the future especially when hermes um you know kind of becomes more popular so so you know like what i'm what i'm sensing here is that repack is then a
super fresh development and uh opens up like all great webpack five features and and it's powerful ecosystem so you know what does it mean in practice what kind of features are we talking about yeah so in practice uh we support all of the features that metro does so you could use hermes you can use flippers with all of the reaganity specific plugins like react devtools hermes inspector and and other additionally we have fully fully featured development server so it works out of the box uh you just run different command and that's it so it's it's not a drop in replacement but it's close to and the one of the major benefits of of repack is that now uh we can support uh code splitting in react native so you can split your bundle into multiple files and in the future we will be able to use module federation for developing regulative applications nice and i'm gonna i'm gonna ask you about these uh features in a in a bit because you know this is this is really interesting to talk about module federation code splitting um generally i'm really excited you know like if i were to say what's the biggest selling point for me that would be definitely siblings because that just makes my development easier but um i guess you know jokes aside that's that's that's that's not the primary reason why somebody should be choosing repack over metro actually in the readme of the project that i have checked uh you know beforehand uh you explicitly say that it is targeted at you know advanced developers and
that said i'm curious what are these scenarios that make using your library a no-brainer and i guess we are talking about something a bit more advanced than just um than just what i said right yeah so uh let's start with with the basics so uh one of the use cases that webpacks really shines in are projects that have complex or unconventional project structure so uh one of the example is having git sub modules or siblings like you mentioned those those are the cases when uh it's it might be not possible to bundle your application properly with metro but with webpack it is possible to configure it to properly resolve all of the source files all of the dependencies regardless where they are so that's one one group of the of the projects that would benefit from repack another one are the applications that itself could benefit from code splitting uh so we we have a lot of applications that could benefit from it a few examples are modular applications when you have a logic that you don't want to ship to all of the users but you want to load them on demand for example for only specific group of users based on some factors that you detect in the runtime let's say user subscriptions plan right one one another uh example of applications are so called super apps when you have one big application that consists of multiple uh smaller apps and you don't let's say you have a super app that includes 50 mini apps you don't want to ship all of the mini apps to the end user you want to ship the least amount possible and download
the rest on demand if the user wants to use that app and in general all of the applications that uh that wants to download uh the the code or extend functionality in runtime on demand uh another option is some kind of text processor when based on the language you write you detect what language the user is using and then you want to download some code for analytics or on some ai based for that specific language yeah that that that sounds really interesting and uh you mentioned quite a few very interesting use cases uh like those mini apps or super apps and you know and and like the way you could potentially build your application have those dynamic pieces downloaded that's really interesting and i guess these are you know the the projects that become more and more popular with react native visit matures but you also said that you know these are the projects that would greatly benefit from using repack so what kind of benefits are we talking about here uh is that you know dti or something else word kind of tti is one of them because the the less code you ship and parse and the value weight at the start type and startup time then the the less time is spent so you can quicker get to interactive point of the of your app time to render is also a metric that would benefit from code splitting especially if you combine code splitting with hermes where you can remove the parsing part of running your code at startup altogether because that's part is done at build time so then the only thing is to just evaluate the least amount of code possible
and load the rest later once it's needed so that's one of the one of the reason where uh tti or ttr can be improved another one is just basically being able to load content on demand it is possible with metro but there are few challenges and it's limited uh to to do that so it's not something that is well researched or well investigated while code splitting has been around four years in web development community and webpack has a great support for it so why shouldn't we benefit when writing reagan applications for that another benefit that you would get in the future with module federation is battle scalability of of your teams this is mostly for the bigger companies or enterprise companies that has a lot of that have a lot of teams so with module federation you would be able to give control of the of the built pipeline to each of the teams separately so each of the teams can develop their part of the application in isolation individual from from the rest of the team and then they control that build process so they can tweak it to their needs they can add dependencies that they want and then they build the so-called container but we can say it's a bundle they build their own bundle and in the final step all of the bundles from all of the teams are being put together into react native application and that application will run everything uh accordingly to your functionality so it's easier to to work in isolation and it's easier uh to scale your teams of motor federation yeah and um that that that last example that you said is
very interesting because um you said that uh you can have your each of your teams to work separately build it the way they want and at the end of the day you can combine it into a single app and that pretty much sounds like having your own app store having your own sdk and platform and if we change your different teams with different companies all around the world it seems that with repack and module federation and can build something like a platform say react native for tv os that's gonna be a like a a os and with modular federation i can build like an app store sdk and others can target my my environment is that is that is that right sort of um conceptual uh from from the conceptual point of view yes i i think so with module federation the limitations are pretty much endless so uh you can do whatever you want uh mojo federation doesn't only necessarily mean means that you will have one app and uh teams that that build uh bundles you can have teams that require use of some code from other teams it's also perfectly fine fine use case the module federation was created for so-called micro front-ends in web development you can read it online if you want so the the use cases are are huge and with module federation's support in react native thanks to web pack five and and repack you would be able to create your own app store or some kind of host app that would run other applications that are developed not necessarily by your team but they can be developed by external team
you will supply to them development host app it doesn't have to be a production one it can be any basically host app which is a just a regular react native application with uh your mocked api or stopped api and then they can develop for that and at the end of the day they ship the the compiled bundle to you and you pack that into a single application and and ship it to the to the end user and actually you don't even have to bundle that into the final application you can also host it on the server and your react native application the production host app will download the bundle that the external team created from the server so the possibilities are endless yeah that's that's that sounds really you know like i know that i'm saying that you know oh your answer sounds really exciting but this is actually very interesting piece of technology and uh you know um it is really interesting to see that by doing something that looks you know at the first side very standard like oh here we're just gonna make webpack uh support for react native you can enable so many great features like this is uh this is really you know a surprise but at the same time it shows that uh you know you can essentially um use tools that are already in the market to create something very very challenging and extraordinary so um at the very end uh you mentioned that you don't necessarily need to bundle it with your app you can put it on the server so my first um my first thought is you know code push which is kind of kind of the same let's say uh i mean you can dynamically
extend your functionality uh like write something like new module and you know push code push update so um i know that the repack is different but just to make it clear for everybody like what's the difference between code push and the dynamic delivery done with repack yeah so function uh essentially the difference lies in both mechanism how it works and the use case with code push uh once you have your update this update will be downloaded by direct native application and it will overwrite your existing bundle and this is usually a single bundle and then on the next restart of the app the new updated bundle will be loaded so you will get the new code that you deployed to the code push but with re-park and the code splitting module federation you can load the functionality into your already running application at the same time you don't even you don't have to restart the application to to use the functionality that got downloaded and evaluate it so this is a different mechanism how it works and different use case the code push it's great for shipping fixes or changing some some small stuff in inside your bundle but code splitting and module federations allow you to write different kind of architectures for your applications where you only load code to either specific group of users for example you have e-learning applications and you have most of the users are students and you don't want to load functionalities for the teachers so you don't ship that functionality by default
and if if teacher logs in you detect that he's a teacher or they are teacher and then you download the the bundle for the teacher yeah yeah very good example thanks for making this clear i actually also have like an example i guess that works here which is very close uh for example to my area of interest which would be you know the automotive app to control your car probably as soon as you select your make and model or maybe put your id number you get download like the app could download the specific functionality for your particular make so um that makes sense cool so um you know we have talked about a lot of different features and uh it's great to hear that while we initially started talking about the performance we ended up also talking about some interesting use cases which means that repack is is not only about performance but it's also about bringing some really interesting use cases into into practice but i'm gonna stick to the performance for a second because a few questions before we have talked about tti that you know um that apps can benefit from can improve dti when using repack and uh i i i guess you know i just wanted to ask if you have done any benchmarking around that use case uh what kind of improvements are we uh possibly talking about uh unfortunately no we haven't done any benchmarks yet uh we plan to do them uh later uh right now uh with repack we are in kind of early stages uh which means we have all of the features that we need for the future parity of metro uh we have basic support for code
splitting in forms of asynchronous chunks but we first want to focus on delivering improved support for code splitting and implement module federation's support first and then we can do that benchmarking because now we will have a final base for uh for the benchmarking without motor federation support and improved uh code splitting support it's hard to benchmark it because the benchmarks can be invalid or will be invalid later once we change the code yeah that that is a good approach and i'm going to ask you about uh the future plans uh in a um in a second there is one more question that i just figured um that i would ask you regarding performance um which is related to um what you said before that with repack you can actually uh load the code into the already running application now um i have actually done a bit of research and i know that there are people out there uh that we're or are trying to achieve uh a similar functionality to repack by instantiating multiple bridges like one two three four bridges and you know like the bridge api for example in ios you can init bridge with url for example so they would in it a bridge for every chunk let's say every react native app and they would create an abstraction to asynchronously communicate with the bridges i guess with repack uh you go for much better approach because there is just one i guess so so that also means some memory benefits i guess um if you could just help me um understand and maybe explain to others
the differences here because i guess some people that are interested in this topic might have seen that multi-bridge solution let's say yeah so i think the feasibility of solutions with having just a single bridge and multiple bridge should be evaluated by case by case uh it's hard to generalize for that but with re-pack you can have both or you can migrate to to both uh let's talk about the situation with the uh single uh react instance and single react instance also has a single javascript context so uh you could have single one and just share it across and load the the chunks the the code that you split it into it on demand this is most of the cases you would use that but if for some reason and this is this has to be specific to your case and your project you decide that you want to have multiple react instances and you're fine with the uh the drawbacks that go with it then react repack can also help you with that because now you could just have a index bundle host bundle you can name it however you want the first bundle that gets loaded that contains your dependencies and then each of the react instance will load only their specific chunk that they need to to access so instead of uh loading the whole bundle for with all of all of the chunks and just using part of the functionality in each of the react instance you have each of the react instance load the dependencies the minimal amount of runtime and then only the functionality that is specific to that
react instance so you save a on the memory and on the time especially on the start in that scenario yeah that that that makes a lot of sense and it actually shows me that with repack i just have more control i can choose one bridge multiple ones and and and what is most important to me is is the ability to actually avoid like instantiating react native within every bridge i guess what what is happening these days is that if somebody does three or four bridges they just duplicate the runtime in these multiple places so that's definitely something that they should not be doing okay uh cool so i have one last question i guess we have covered pretty much everything i guess regarding code splitting but i'm pretty sure there is still like hours of discussions on use cases so if anybody is interested uh just give us some ideas we can probably will probably discuss some of these projects uh in our podcast but before we uh drop off um i just wanted to ask you like um you know how can i get started this this all sounds very interesting and you know sounds like something that i'd love to start using now is this all already available how can i get started what's the plan here yeah so good news it's already available we have we have a repo for that on github it's already published to an npm the code is open source of course and we are at the stage where we have a feature parity with metro except for ram bundles which we deliberately choose not to support uh so you can replace metro if you want right now uh and we have a
basic support for code splitting meaning that you can use so-called asynchronous chunks by uh writing a dynamic import function inside your code that will create a chunk this has some limitations and you can read more about it in our readme but we are working right now on improving this support so that those chunks you will have a better control over where those chunks are stored so you will be able to store them in up so that the chunk will be packed inside your apa or apk file or you will be able to store them on the server and load from their remote location so we are working on bringing that functionality alongside other apis for the chunk management like invalidation of the cache and and what's what's so not um then we are focusing on bringing the modern federation into react native because uh we think that's a game changer for for writing complex regulated applications so that's our plan you can already use it but you will have to wait a bit for all of the the good stuff that we just started in this podcast which i guess is a nice thing to be waiting for you'll probably definitely tease us all about what's coming up because i'm pretty sure that you know these use cases are something that a lot of developers at least once in their lifetime uh have stumbled upon so pablo thank you very much it's been pleasure to have this podcast today with you during this beautiful sunny day um i hope that you enjoyed it and that's not gonna be uh the last time we are having this
podcast what you think yeah definitely uh we can do more podcasts in the futures uh if there are any uh any questions or any topics that that we should cover let's just do it and yeah thank you for having me today nice thanks pavo now i have it on tape so i'll definitely be uh getting back to you uh anyway uh um yeah that brings us to the end of this podcast uh thanks uh thank you everybody for you know watching us listening guys ass depend regardless of the platform that you are consuming this podcast just a casual reminder that uh you can follow us on twitter uh you can check our youtube account where you know the video that you are maybe listening to is available if you prefer audio podcasts we also um probably are on every platform uh to find the available platforms just go to callstack.
com
react native show and um you will have all the links and our previous episodes there to enjoy so with that said thank you pawel once again thanks everybody and see you on the next episode of react native show
Timestamps
Show
Listen on Spotify
Watch on YouTube
Listen on SoundCloud
Listen on Apple Podcasts
Guests
Paweł Trysła
Software Engineer
@
Callstack
[Music] hello everybody and welcome to another react native show episode today we are going to talk about repack and a very interesting open source library that uses webpack so we're gonna learn what this has to do with react native and why you should be probably using it today with me is a very special guest travel that works with me at call stack so papa very nice to not meet you because we know each other but i'm pleased to have you on this podcast uh so you know how about you just introduce yourself in a couple of words for those of our listeners that are here you know for the first time before we go into the repack and all the benefits that it has uh yeah uh hi mike uh thanks for having me uh i'm pavel also known as zamotani on the internet uh like like i said uh i work here at kolstek i'm a software developer for more than four years now um really excited to be here nice great i'm also really excited to have you today because we have a very special topic that uh you know is something that you've been working on for a while now so you know i know the name is repack uh what can you tell me about this project okay so repack is uh a direct successor to whole hall was also a open source project that we did here at call stack and essentially a repack is a toolkit for react native applications that works with webpack so webpack is a bundler for your uh javascript or typescript code and you use repack to make that bundle that webpack generates work with react native so while webpack is a bundler repack is a
toolkit or set of apis that allows you to use webpack for developing regnative applications it has support for features like hermes flipper or react refresh and we plan to add more features that are exclusively available in webpack which you cannot for example do in metro wow that's quite a lot of keywords in a single answer and i guess before we go into the details it would be great to talk about some basics like for example what do we need a bundler for in context of react native uh if we are actually building a mobile application yeah so when we are writing the code for the reg native we usually write it in javascript or typescript and this code is split between multiple files right your source code the consists of multiple files and you also have dependencies that lives in for example node modules uh so those files might contain a syntax that is not well understood by the javascript vm uh for example you're using arrow functions or cons on that this is the syntax that might not be uh not be supported yet in javascript vm so you have all these files that are not runnable right now and you need a way to pack them together into a single or few smaller files and transform them at the same time to something that the javascript vm understands and this is what the webpack does it takes your code it transpiles it for example with bubble and packs it together alongside minification happens to make sure that you ship the smallest possible code without any comments or additional stuff that affects the size because the less code you write the
less time spent on evaluating and processing that code yeah and i guess you know for for that reason facebook had to develop petrol i mean i guess we'll get into that a bit later but um there is already metro in react native which is kind of the default and every time you actually install a react native locally on your machine this is what you get so i guess what would be the biggest selling point of repack if i were to use it over metro so the biggest selling point of repack is that it's based on webpack repack itself is not a bundler so it's not a direct competitor to to metro but it's a set of apis that will make webpack a bundler for regulated applications so uh the the biggest selling point like i said is webpack because it's support it supports a lot of features that are not otherwise available for real native developers like you have this whole ecosystem of webpack loaders plugins and the vast amount of configuration options so the strength of of repack is that is based on the webpack essentially and the webpack has been uh in the market for years now and has a widespread adoption especially in the uh web development community yeah that that makes a lot of sense and uh you know before before doing this podcast um i also did a bit of research and um you know it turns out that there was actually an attempt to use webpack with react native early days uh just before the facebook team decided to build a packager later rephrase to metro in a separate project and i guess uh there is also an issue issue number five
uh that you know we have linked to this article so we can go and check it out but i guess the primary reason uh webpack was not used was performance and lack of support for some facebook specific things like i guess you know haste modules that some of you may not remember but they were quite popular back in the day you know back to the hall which is you know like uh predator to repack i'm just curious is that also why this project despite being i guess quite popular and conceptually offering the same thing as repack never really got to the point where you were kind of satisfied with it and had you know stable features set um and you know eventually now it is sort of discounted in favor of reebok so i'm just trying to understand what specifically led to that decision um that whole never really got into you know a stable phase yes so the main problem with hull was its architecture we designed hull to encapsulate webpack under the hood so whole had its own configuration file and we had to maintain that configuration file we had to maintain all the documentation for it uh while we still were using webpack under the hood and had to convert from our configuration file format to parts one so so that we can actually run uh and because we hit uh webpack uh behind this arcade uh the issues that people had with webpack were also our issues because they were opening uh new issues on github to our project instead of webpack while a lot of the problems that developers had were already solved and you could find
them on webpack's github so that was the one thing and another was that because of this uh maintenance overhead the the feature development velocity was low so it was difficult to develop new features and sometimes even impossible or not visible like in case of react refresh the whole architecture didn't really work in a way that would allow us to do that especially since we had to also support run bundles which complicated the whole code uh to a point that it was just not possible to to implement latest and greatest features that that metro had yeah yeah that that that makes a lot of sense and i can definitely relate that over time i've also learned that sometimes building these nice abstractions while making it easier for developers to use sometimes it's just not paying off in the long term so uh you know i'm curious what was the game changer for you that you know made building repack possible i guess you're now more like you're now satisfied with you know the way repack looks like and still it is based on web packs so what is different now about repack or webpack or your approach that makes repack such a good alternative and actually something that you believe uh is going to be working really nicely yeah so there were three things that that allowed us to to create uh repack and support all of the features that that metro has so the first one is the release of webpack five that was a game changer for us the a lot of the internal code was refactored in web.
5 which
makes it easier to understand and read
the source code which was the reason why we could create for example how the module replacement with react refresh support into repack the other thing was that instead of hiding weapon configuration we now embrace it so the developers have access and they own weapon configuration and they just use our apis like plugins to to tweak the configurations to to their needs so whenever the developer have have an issue with weapon configurations let's say some loader doesn't work as they expect or something is not transpired properly they can search directly for that issue inside webpacks github repository or somewhere on the internet on stack overflow or something the last part is that we've decided not to support uh run bundles it was our deliberate decision based on the experience we've got with hull since the support for ram bundles complicates the the code exponentially so if we were to support run bundles we probably wouldn't be able to support react refresh so we opted for the greater developer experience instead of having having to support ram bundles uh since they are not that widely used yeah and that makes a lot of sense i guess sometimes you just gotta make these decisions about that supporting everything especially when you know the future of certain features is not really settled yet and it may happen that ram bundles are not popular in the future especially when hermes um you know kind of becomes more popular so so you know like what i'm what i'm sensing here is that repack is then a
super fresh development and uh opens up like all great webpack five features and and it's powerful ecosystem so you know what does it mean in practice what kind of features are we talking about yeah so in practice uh we support all of the features that metro does so you could use hermes you can use flippers with all of the reaganity specific plugins like react devtools hermes inspector and and other additionally we have fully fully featured development server so it works out of the box uh you just run different command and that's it so it's it's not a drop in replacement but it's close to and the one of the major benefits of of repack is that now uh we can support uh code splitting in react native so you can split your bundle into multiple files and in the future we will be able to use module federation for developing regulative applications nice and i'm gonna i'm gonna ask you about these uh features in a in a bit because you know this is this is really interesting to talk about module federation code splitting um generally i'm really excited you know like if i were to say what's the biggest selling point for me that would be definitely siblings because that just makes my development easier but um i guess you know jokes aside that's that's that's that's not the primary reason why somebody should be choosing repack over metro actually in the readme of the project that i have checked uh you know beforehand uh you explicitly say that it is targeted at you know advanced developers and
that said i'm curious what are these scenarios that make using your library a no-brainer and i guess we are talking about something a bit more advanced than just um than just what i said right yeah so uh let's start with with the basics so uh one of the use cases that webpacks really shines in are projects that have complex or unconventional project structure so uh one of the example is having git sub modules or siblings like you mentioned those those are the cases when uh it's it might be not possible to bundle your application properly with metro but with webpack it is possible to configure it to properly resolve all of the source files all of the dependencies regardless where they are so that's one one group of the of the projects that would benefit from repack another one are the applications that itself could benefit from code splitting uh so we we have a lot of applications that could benefit from it a few examples are modular applications when you have a logic that you don't want to ship to all of the users but you want to load them on demand for example for only specific group of users based on some factors that you detect in the runtime let's say user subscriptions plan right one one another uh example of applications are so called super apps when you have one big application that consists of multiple uh smaller apps and you don't let's say you have a super app that includes 50 mini apps you don't want to ship all of the mini apps to the end user you want to ship the least amount possible and download
the rest on demand if the user wants to use that app and in general all of the applications that uh that wants to download uh the the code or extend functionality in runtime on demand uh another option is some kind of text processor when based on the language you write you detect what language the user is using and then you want to download some code for analytics or on some ai based for that specific language yeah that that that sounds really interesting and uh you mentioned quite a few very interesting use cases uh like those mini apps or super apps and you know and and like the way you could potentially build your application have those dynamic pieces downloaded that's really interesting and i guess these are you know the the projects that become more and more popular with react native visit matures but you also said that you know these are the projects that would greatly benefit from using repack so what kind of benefits are we talking about here uh is that you know dti or something else word kind of tti is one of them because the the less code you ship and parse and the value weight at the start type and startup time then the the less time is spent so you can quicker get to interactive point of the of your app time to render is also a metric that would benefit from code splitting especially if you combine code splitting with hermes where you can remove the parsing part of running your code at startup altogether because that's part is done at build time so then the only thing is to just evaluate the least amount of code possible
and load the rest later once it's needed so that's one of the one of the reason where uh tti or ttr can be improved another one is just basically being able to load content on demand it is possible with metro but there are few challenges and it's limited uh to to do that so it's not something that is well researched or well investigated while code splitting has been around four years in web development community and webpack has a great support for it so why shouldn't we benefit when writing reagan applications for that another benefit that you would get in the future with module federation is battle scalability of of your teams this is mostly for the bigger companies or enterprise companies that has a lot of that have a lot of teams so with module federation you would be able to give control of the of the built pipeline to each of the teams separately so each of the teams can develop their part of the application in isolation individual from from the rest of the team and then they control that build process so they can tweak it to their needs they can add dependencies that they want and then they build the so-called container but we can say it's a bundle they build their own bundle and in the final step all of the bundles from all of the teams are being put together into react native application and that application will run everything uh accordingly to your functionality so it's easier to to work in isolation and it's easier uh to scale your teams of motor federation yeah and um that that that last example that you said is
very interesting because um you said that uh you can have your each of your teams to work separately build it the way they want and at the end of the day you can combine it into a single app and that pretty much sounds like having your own app store having your own sdk and platform and if we change your different teams with different companies all around the world it seems that with repack and module federation and can build something like a platform say react native for tv os that's gonna be a like a a os and with modular federation i can build like an app store sdk and others can target my my environment is that is that is that right sort of um conceptual uh from from the conceptual point of view yes i i think so with module federation the limitations are pretty much endless so uh you can do whatever you want uh mojo federation doesn't only necessarily mean means that you will have one app and uh teams that that build uh bundles you can have teams that require use of some code from other teams it's also perfectly fine fine use case the module federation was created for so-called micro front-ends in web development you can read it online if you want so the the use cases are are huge and with module federation's support in react native thanks to web pack five and and repack you would be able to create your own app store or some kind of host app that would run other applications that are developed not necessarily by your team but they can be developed by external team
you will supply to them development host app it doesn't have to be a production one it can be any basically host app which is a just a regular react native application with uh your mocked api or stopped api and then they can develop for that and at the end of the day they ship the the compiled bundle to you and you pack that into a single application and and ship it to the to the end user and actually you don't even have to bundle that into the final application you can also host it on the server and your react native application the production host app will download the bundle that the external team created from the server so the possibilities are endless yeah that's that's that sounds really you know like i know that i'm saying that you know oh your answer sounds really exciting but this is actually very interesting piece of technology and uh you know um it is really interesting to see that by doing something that looks you know at the first side very standard like oh here we're just gonna make webpack uh support for react native you can enable so many great features like this is uh this is really you know a surprise but at the same time it shows that uh you know you can essentially um use tools that are already in the market to create something very very challenging and extraordinary so um at the very end uh you mentioned that you don't necessarily need to bundle it with your app you can put it on the server so my first um my first thought is you know code push which is kind of kind of the same let's say uh i mean you can dynamically
extend your functionality uh like write something like new module and you know push code push update so um i know that the repack is different but just to make it clear for everybody like what's the difference between code push and the dynamic delivery done with repack yeah so function uh essentially the difference lies in both mechanism how it works and the use case with code push uh once you have your update this update will be downloaded by direct native application and it will overwrite your existing bundle and this is usually a single bundle and then on the next restart of the app the new updated bundle will be loaded so you will get the new code that you deployed to the code push but with re-park and the code splitting module federation you can load the functionality into your already running application at the same time you don't even you don't have to restart the application to to use the functionality that got downloaded and evaluate it so this is a different mechanism how it works and different use case the code push it's great for shipping fixes or changing some some small stuff in inside your bundle but code splitting and module federations allow you to write different kind of architectures for your applications where you only load code to either specific group of users for example you have e-learning applications and you have most of the users are students and you don't want to load functionalities for the teachers so you don't ship that functionality by default
and if if teacher logs in you detect that he's a teacher or they are teacher and then you download the the bundle for the teacher yeah yeah very good example thanks for making this clear i actually also have like an example i guess that works here which is very close uh for example to my area of interest which would be you know the automotive app to control your car probably as soon as you select your make and model or maybe put your id number you get download like the app could download the specific functionality for your particular make so um that makes sense cool so um you know we have talked about a lot of different features and uh it's great to hear that while we initially started talking about the performance we ended up also talking about some interesting use cases which means that repack is is not only about performance but it's also about bringing some really interesting use cases into into practice but i'm gonna stick to the performance for a second because a few questions before we have talked about tti that you know um that apps can benefit from can improve dti when using repack and uh i i i guess you know i just wanted to ask if you have done any benchmarking around that use case uh what kind of improvements are we uh possibly talking about uh unfortunately no we haven't done any benchmarks yet uh we plan to do them uh later uh right now uh with repack we are in kind of early stages uh which means we have all of the features that we need for the future parity of metro uh we have basic support for code
splitting in forms of asynchronous chunks but we first want to focus on delivering improved support for code splitting and implement module federation's support first and then we can do that benchmarking because now we will have a final base for uh for the benchmarking without motor federation support and improved uh code splitting support it's hard to benchmark it because the benchmarks can be invalid or will be invalid later once we change the code yeah that that is a good approach and i'm going to ask you about uh the future plans uh in a um in a second there is one more question that i just figured um that i would ask you regarding performance um which is related to um what you said before that with repack you can actually uh load the code into the already running application now um i have actually done a bit of research and i know that there are people out there uh that we're or are trying to achieve uh a similar functionality to repack by instantiating multiple bridges like one two three four bridges and you know like the bridge api for example in ios you can init bridge with url for example so they would in it a bridge for every chunk let's say every react native app and they would create an abstraction to asynchronously communicate with the bridges i guess with repack uh you go for much better approach because there is just one i guess so so that also means some memory benefits i guess um if you could just help me um understand and maybe explain to others
the differences here because i guess some people that are interested in this topic might have seen that multi-bridge solution let's say yeah so i think the feasibility of solutions with having just a single bridge and multiple bridge should be evaluated by case by case uh it's hard to generalize for that but with re-pack you can have both or you can migrate to to both uh let's talk about the situation with the uh single uh react instance and single react instance also has a single javascript context so uh you could have single one and just share it across and load the the chunks the the code that you split it into it on demand this is most of the cases you would use that but if for some reason and this is this has to be specific to your case and your project you decide that you want to have multiple react instances and you're fine with the uh the drawbacks that go with it then react repack can also help you with that because now you could just have a index bundle host bundle you can name it however you want the first bundle that gets loaded that contains your dependencies and then each of the react instance will load only their specific chunk that they need to to access so instead of uh loading the whole bundle for with all of all of the chunks and just using part of the functionality in each of the react instance you have each of the react instance load the dependencies the minimal amount of runtime and then only the functionality that is specific to that
react instance so you save a on the memory and on the time especially on the start in that scenario yeah that that that makes a lot of sense and it actually shows me that with repack i just have more control i can choose one bridge multiple ones and and and what is most important to me is is the ability to actually avoid like instantiating react native within every bridge i guess what what is happening these days is that if somebody does three or four bridges they just duplicate the runtime in these multiple places so that's definitely something that they should not be doing okay uh cool so i have one last question i guess we have covered pretty much everything i guess regarding code splitting but i'm pretty sure there is still like hours of discussions on use cases so if anybody is interested uh just give us some ideas we can probably will probably discuss some of these projects uh in our podcast but before we uh drop off um i just wanted to ask you like um you know how can i get started this this all sounds very interesting and you know sounds like something that i'd love to start using now is this all already available how can i get started what's the plan here yeah so good news it's already available we have we have a repo for that on github it's already published to an npm the code is open source of course and we are at the stage where we have a feature parity with metro except for ram bundles which we deliberately choose not to support uh so you can replace metro if you want right now uh and we have a
basic support for code splitting meaning that you can use so-called asynchronous chunks by uh writing a dynamic import function inside your code that will create a chunk this has some limitations and you can read more about it in our readme but we are working right now on improving this support so that those chunks you will have a better control over where those chunks are stored so you will be able to store them in up so that the chunk will be packed inside your apa or apk file or you will be able to store them on the server and load from their remote location so we are working on bringing that functionality alongside other apis for the chunk management like invalidation of the cache and and what's what's so not um then we are focusing on bringing the modern federation into react native because uh we think that's a game changer for for writing complex regulated applications so that's our plan you can already use it but you will have to wait a bit for all of the the good stuff that we just started in this podcast which i guess is a nice thing to be waiting for you'll probably definitely tease us all about what's coming up because i'm pretty sure that you know these use cases are something that a lot of developers at least once in their lifetime uh have stumbled upon so pablo thank you very much it's been pleasure to have this podcast today with you during this beautiful sunny day um i hope that you enjoyed it and that's not gonna be uh the last time we are having this
podcast what you think yeah definitely uh we can do more podcasts in the futures uh if there are any uh any questions or any topics that that we should cover let's just do it and yeah thank you for having me today nice thanks pavo now i have it on tape so i'll definitely be uh getting back to you uh anyway uh um yeah that brings us to the end of this podcast uh thanks uh thank you everybody for you know watching us listening guys ass depend regardless of the platform that you are consuming this podcast just a casual reminder that uh you can follow us on twitter uh you can check our youtube account where you know the video that you are maybe listening to is available if you prefer audio podcasts we also um probably are on every platform uh to find the available platforms just go to callstack.
com
react native show and um you will have all the links and our previous episodes there to enjoy so with that said thank you pawel once again thanks everybody and see you on the next episode of react native show
Show Transcript

Mike and Paweł share some details about what Re.Pack is and explain how it works. After a short introduction, Paweł explains what developers need the bundler for in the context of building React Native applications and how Re.Pack is different from the default bundler developed by Meta engineers - Metro.

Introduction to Re.Pack

  • What Re.pack is and how it works
  • Biggest selling points of Re.Pack
  • Use of bundler in building React Native apps
  • Biggest selling points of Re.Pack compared with Metro
  • Re.Pack use cases - mini-apps and super-apps
  • Benefits of using Re.Pack

Re.Pack use cases and future plans

Our experts talk about the origins of Re.Pack and reveal the reasons why the toolkit has replaced its predecessor - Haul. Also, Paweł describes what kind of Webpack 5 features are supported by Re.Pack and can be used by developers.  

Also, Mike and Paweł talk about the scenarios of using Re.Pack. You’ll hear about what kind of apps are the best candidates for code splitting and what are the benefits of this solution including, for example, performance optimization, dynamic content delivery, loading logic on demand and many more.

At the end, having all the nurturing topics covered, Paweł shares some details about the future plans for the development of Re.Pack.

Summary

Planning a super app with React Native?

We help architect and develop super apps using modular, scalable designs.

Let’s chat
Link copied to clipboard!
//
Insights

Learn more about

Super Apps

Here's everything we published recently on this topic.

Sort
//
Super Apps

We can help you move
it forward!

At Callstack, we work with companies big and small, pushing React Native everyday.

Super App Development

Turn your application into a secure platform with independent cross-platform mini apps, developed both internally and externally.

Module Federation Development

Use Module Federation to provide dynamic features within React Native mobile applications post-release.