Define how to build Microapps with bundle workflow

[rosen-vladimirov]

Is your feature request related to a problem? Please describe.
As in NativeScript 6.0 bundle workflow will be the only one, we need to find a way to build Microapps with it. More information about Microapps is available here
The problem with them is that there's a single NativeScript application (lets call it container) and differente micro applications can be installed in it. When the container application is built with webpack, the application will include only the node_modules used by the container app. This limits the modules that can be used by the Microapps. Also, the code of the container will not contain node_modules - all of them will be in the vendor.js file produced by webpack. The code of the Microapps is not bundled by default, its just pure JavaScript. This means the code of the Microapps will have require statements, which will fail, as there are no node_modules in the built application. They can be accessed via webpack require, but this means the Microapps will have to be build with bundle. By default, the Microapps are not build at all, they are just pure JavaScript.

Describe the solution you'd like
Provide guidelines and easy way to configure application in a way that all node_modules will be transferred to the native mobile app. Extend this by allowing these node_modules to be consumed by external JavaScript code loaded in the app (i.e. which is not part of the application during building it).

Describe alternatives you've considered
Provide alternate way of building applications without webpack.

[DimitarTachev]

The node_modules are now properly included in the bundled app by:

• marking them as externals in order to exclude them from vendor.js. (externals is a Webpack configuration excluding dependencies from the output bundles).
• copying them to the output directory using the Webpack Copy Plugin.
• transpiling the copied node_modules to common-js modules using nativescript-dev-babel (the NativeScript Runtimes require common-js modules).

In addition, the dynamic require calls for pages of Micro Apps are replaced with __non_webpack_require__ in order to be skipped by the Webpack compilation.

[NathanaelA]

@DimitarTachev - Maybe I totally misunderstand the solution you have tested/proposed???

Can you go into more indepth how these work -- Both scenarios I can think of based on what you provided have some pretty significant major negative side effects -- it seems like you are eliminating the majority of what webpack provides... Are you really basically eliminating webpack for the vendor.js file? (so i.e. no vendor.js; everything's back in the node_modules?) You then lose the majority of the speed increase and file shrinking that webpack provides. Or did I misunderstand what you are proposing?

[DimitarTachev]

Hi @NathanaelA,

Thanks for looking into this and providing your feedback!

I will start with a little more context. We have a few special apps that are deployed to the app stores with some sample content which is dynamically replaced at runtime - e.g. the NativeScript Preview app and the MicroApps container app.

Till now, all of these apps were built using the Legacy Workflow and the node_modules were copied without any tree shaking by the NativeScript CLI. Starting from NativeScript 6.0.0, we will not be able to do that and in order to keep this content replacement fast and reliable, we had to do something based on the following requirements:

The examples below are based on the Preview app

1. We are not able to run a Webpack process in the browser and the NativeScript Playground is sending only the app/src folder containing a lot of require statements to the Preview app. This means that in the Preview app we should override only the app folder and all of the node_modules should already be in place. In general, we can send the whole node_modules folder (we don't have a Webpack process to tree shake them) from the Playground to the Preview App, but this will make the preview much much slower and we will hit a limitation described below in point (2).
2. The NativeScript Android Runtime should be able to find the JavaScript instance of the Preview app Android Activity at the location specified by the SBG (Static Binding Generator) during the Gradle build of the Preview App itself. By default, this activity is used from tns-core-modules which are part of vendor.js. In other words, we have to keep the original vendor.js file when overriding the app content. (this is resolved by marking the tns-core-modules as externals, manually handling the node_modules and not overriding them in Preview).

Regarding your concerns, yes, they are correct and it is by design, for these container apps we are eliminating everything that Webpack provides for the node_modules. No tree shaking, no speed improvements (the build will take a few minutes). In this way, we ensure that whatever app is synced in the container app, we will able to resolve its require calls from node_modules. In addition, as I already said, the container apps contain just a sample JavaScript content and we are just updating their dependencies on each NativeScript release. We do not have an active development there. The active development is in the playground, the local apps when using tns preview or the MicroApps where we do not process anything from node_modules, we just mark the dependencies available in the container app as externals providing very fast and reliable livesync to the corresponding container app.

I hope this clarifies the issue. Any feedback and ideas are appreciated :)