-
-
Notifications
You must be signed in to change notification settings - Fork 136
[FR] Customize metadata generation to avoid adding unnecessary unused JS wrappers #1485
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Not necessary to be a breaking change. It could be done only if the user wants it. |
Implementing this could also allow capability based security of some kind in order to mitigate malicious plugins. |
Sure, the app can have the final word. But what happens if some plugin adds such a configuration and the app hasn't? But you're right, it's not necessary to be a breaking change -- we can still generate all metadata if the app hasn't turned on some switch. |
How about implementing this feature:
|
Seems to be too limited in functionality and will require more manual work by everyone who decides to opt for it, as users will have to take into account all their plugins' JS implementation and the underlying native APIs it uses. |
Config requirementsIt seems like it comes down to this:
Potential approachesWe then have a question of how the app's configuration is interpreted, in the case that it is explicitly given. There are three simple approaches:
I think the If we additionally allowed some way to override, at app level, the specified native API dependencies of all plugins used by the app, then we'd be able to solve both the issues of multi-purpose plugins and the issues of older plugins that lack explicit native API dependency declarations. Config file formatFor each pluginSo maybe each plugin should have a file, Note: I haven't looked too closely at what the exact native dependencies of module.exports = {
/* The plugin's native API dependencies.
* These will be used implicitly unless overridden by the app. */
"__self__": [
/* Foundation and CoreFoundation will be pretty common,
* so we may want to agree on a minimal implicit set.
* But that's a separate discussion. */
"Foundation",
"CoreFoundation",
"UIKit",
"WebKit"
]
}; For the app itselfApps that don't call native APIs other than via the plugins wouldn't need to specify their own module.exports = {
/* The app's native API dependencies.
* These will be unioned with those of the plugins. */
"__self__": [
"AVFoundation"
],
/* Here we override the dependencies specified by a plugin. */
"nativescript-syntax-highlighter": [
"Foundation",
"CoreFoundation",
"UIKit",
/* In the case that we know that we're not going
* to use any of the WebKit-related features */
// "WebKit"
]
}; Thoughts? |
Uh oh!
There was an error while loading. Please reload this page.
Is your feature request related to a problem? Please describe.
Currently, the whole Android SDK and all native libraries used in a {N} app are included in the metadata binary files. In order to reduce app size and improve startup performance, we should allow app/plugin developers to specify which entities (e.g. Java packages) need to actually be accessible from JavaScript.
Additional context
Things to consider:
An idea for UI which helps generate these lists from @shirakaba: Polyfill.io shows one user interface by which one could generate a package by specifying only the libraries that one needs. Maybe something like this could be applied to the NativeScript runtimes: https://polyfill.io/v3/url-builder/
Corresponding feature request in iOS runtime is: NativeScript/ios-jsc#1209
Implemented in {N} CLI with: NativeScript/nativescript-cli#5220
The text was updated successfully, but these errors were encountered: