NativeScript / nativescript-cli

Command-line interface for building NativeScript apps
https://www.npmjs.com/package/nativescript
Apache License 2.0
1.04k stars 195 forks source link

[android] packaged aar should be by modules appearing after webpack compilation #4400

Open farfromrefug opened 5 years ago

farfromrefug commented 5 years ago

I now use webpack-strip-block in my app to remove code in production. The idea behind this is to be able to use nativescript-vue-devtools in dev but obviously remove it in production. So i add this to my webpack

if (!!production) {
        config.module.rules.push({
            test: /\.tsx?$/,
            enforce: 'pre',
            exclude: /node_modules/,
            use: [
                {
                    loader: 'webpack-strip-block',
                    options: {
                        start: 'DEV-START',
                        end: 'DEV-END'
                    }
                }
            ]
        });
    }

and in my app i do something like this:

/* DEV-START */
console.log('only shown in dev', device.model, device.os, device.osVersion, device.manufacturer);
const VueDevtools = require('nativescript-vue-devtools');
Vue.use(VueDevtools);
/* DEV-END */

This works perfectly and the code is removed in prod. So nativescript-dev-tools is not packd in prod. But remains the issue of the native version of the modules. nativescript-dev-tools depends on nativescript-socket-io which has native lib. My issue is that nativescript-socket-io native lib will always be packed with my app even if ``nativescript-dev-toolsis stripped and thennativescript-socket-io``` not packaged.

The list of native module to be added by filtering used packages after webpack compilation (not sure how that list is created right now). It should not be based on the package.json

Hope that issue makes sense

KristianDD commented 5 years ago

Hi @farfromrefug , Currently all native code from plugins is collected based on the dependencies inside the package.json and this was done by design. The main reason to do so is to support plugins that have only native code which is then consumed directly by the JavaScript/TypeScript code inside the application.

We agree that this approach has its downsides and we are currently discussing different options to handle situations like yours. The problem is somewhat complex and we will need some time to evaluate all options. Will update the issue when we have some progress on the matter.

farfromrefug commented 5 years ago

@KristianDD Sure i get the difficulty. Great to know you are looking at solutions. Not actually a big deal right now but it is true that it is something that needs to be fixed. Thanks for your quick answer