Automatic native dependency detection #43
edusperoni
started this conversation in
1. Ideas & Discussions
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. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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 differentpackage.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
frompackage.json
.Pros:
depenencies
linking magic@nativescript/unit-test-runner
when not testing, or some other dependency that is tree-shaken on prod builds)dependencies
, even if it is ondevDependencies
or thedependencies
on a root package.json (monorepos)dependencies
)Cons:
Possible solutions:
I already have a dependency finder that works, so that part is not an issue.
node_modules/@nativescript/webpack
). Add a few config options innativescript.config.ts
allowing 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 in
nativescript.config.ts
as neededAdditionally. 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