-
-
Notifications
You must be signed in to change notification settings - Fork 7
Automatic native dependency detection #43
-
Hello!
Currently, everything under the package.json dependencies will get bundled as a native dependency (cocoapods, implementations, manifests). This results in some odd situations where you might be using a monorepo and didn't include the dependency correctly, or even worse, you have multiple versions of the same dependency because of the multiple declarations in different package.json.
The underlying problem is that the JS build system is decoupled from the Native build system. You can end up with JS code that does not have a corresponding Native code, or Native code that does not have the corresponding JS code. Usually the latter will only increase your bundle size by adding unused native dependencies, but the former will crash your application.
I propose we automatically detect native dependencies by using webpack to analyze them, instead of getting all dependencies from package.json.
Pros:
- no longer needs yarn workspaces or any kind of
depenencieslinking magic - automatically drop not used dependencies (like
@nativescript/unit-test-runnerwhen not testing, or some other dependency that is tree-shaken on prod builds) - simpler to manage for most scenarios
- no longer you have cases where you try to use a plugin only to throw an exception because the plugin isn't included in your
dependencies, even if it is ondevDependenciesor thedependencieson a root package.json (monorepos) - no longer you have native dependencies when you're not actually using the plugin (imagine installing google maps sdk, removing all references to it and then still having the native dependencies in your production app because you forgot to remove from the
dependencies)
Cons:
- More reliant on webpack (the current system would still work as a fallback)
- Very few packages don't have JS code, only native code, which would require manually including them in the build process (or dependencies)
Possible solutions:
I already have a dependency finder that works, so that part is not an issue.
- Analyze dependencies and store them somewhere (temp file, probably under platforms or
node_modules/@nativescript/webpack). Add a few config options innativescript.config.tsallowing the developer to manually specify a blacklist and an include list (for not detected packages)
1.1. We could make the generated json file easily accessible so the developer can more easily look it up and fill the data innativescript.config.tsas needed - Store into a file to be checked into git. This file is automagically updated when new plugins are added so they can be more easily overridden:
{ "@nativescript/core": { "override": false // if this is false we manage it and it can be deleted from/updated to the json. This is how it'd be auto generated }, "@nativescript/core": {}, // alternative, no data = we manage it "@nativescript/payments": { "override": true, // we will never touch this entry "alwaysIncludeNative": true, // always in the native bundle, even if not included in project "ignoreNative": false // if true, never include the native part }, }
Additionally. This could all work in conjunction with the current system (again, using nativescript.config.ts to opt-out of the old system or opt-out of the new system, independently).
No names are final, thoughts would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment
-
@edusperoni i really like your idea. I should add that would really like for N core native deps to be discovered the same way.
Right now it seems to be discovered differently. The issue with that when using a fork of Nativscript, N native deps still gets picked up in @nativescript/core
Beta Was this translation helpful? Give feedback.