NativeScript / NativeScript/nativescript-cli

Allow the use of native ios and android framework's solutions/projects rather than an pre-build .framework/.aar file

Abierto
#4,376 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

feature
Lenguaje dominante
JavaScript
Estrellas
1.1k
Forks
204
Merge medio
1 d 9 h
PR fusionados (30 d)
8

Descripción

Is your feature request related to a problem? Please describe.
At the moment as a plugin developer I have to pre-build my native framework I have from iOS into an embedded .framework file and for Android into an .aar file and place those into the platforms directory of my plugin. I would like to be able to tell the NativeScript CLI where the actual Xcode/Android Studio projects if my plugin are located and have the CLI use them as "referenced projects" for the output that it created in the platforms folder of the {N} application. The idea is to be able to open that output into Xcode/Android Studio and if that output from the CLI is using a referenced of my native framework's solutions they will be included as "side" projects and I will be able to change my native code and use the IDE rebuild and start functionality (like a native iOS and Android development workflow)

Describe the solution you'd like
Currently the CLI creates the output in the the "platforms" directory (after tns build ios/android command) in such a way that it simply uses the pre-build .framework/.aar files from each node_modules {N} plugin into the build Xcode/Android Studio project of the {N} app. If the CLI can instruct the runtime to not simply use and look for .framework/.aar files but instead use an actual Xcode/Android Studio solution which builds those .framework/.aar files it will be possible to implement an functionality into the iOS and Android runtimes that will use those projects.

Describe alternatives you've considered
Currently the only way to streamline the development workflow of a plugin developer who creates a native iOS/Android library is to either:

  1. Build and manually move the product of the library to the "platforms" directory of his plugin
    or
  2. Use the newly created "nativescript-dev-debugging" plugin which provides workflows for such actions

The drawbacks from both approaches is that they require a full build if the {N} app after the library is replaced (--syncAllFiles).

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza siguiendo cómo tns build ios/android crea la salida de la aplicación en el directorio platforms y actualmente consume archivos .framework y .aar de los plugins. Compara ese flujo de trabajo con nativescript-dev-debugging; se considera terminado cuando los proyectos de Xcode y Android Studio proporcionados por los plugins pueden referenciarse, incluirse como proyectos secundarios y reconstruirse mediante el flujo de trabajo del IDE nativo.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
android, ios, javascript
Área
cli, mobile
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
35/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.