NativeScript / NativeScript/nativescript-cli
Use npm's semver rules for plugin's nativescript key
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- JavaScript
- Estrellas
- 1.1k
- Forks
- 204
- Merge medio
- 1 d 9 h
- PR fusionados (30 d)
- 8
Descripción
Problem with plugins verification with runtimes
Currently each NativeScript plugin must have nativescript key in it's package.json and define the minimum required version of each supported runtime. The structure is :
"name": "my-plugin",
"version": "1.0.0",
"nativescript": {
"platforms": {
"ios": "1.5.0",
"android": "1.5.0",
}
}
When tns plugin add my-plugin is executed, CLI checks the values against current runtimes versions and informs the user if a plugin cannot be used with current version.
However CLI uses the specified version in the plugin as minimum required. So for example in case the project uses tns-android 1.6.0, 1.6.2 or even 2.0.0 for example, it can use my-plugin.
This makes it really hard to control the versions against which the plugin is tested and verified by the plugin author.
Suggested solution
Do not reinvent the wheel!
Use semver rules for the nativescript key in package.json, for example:
"name": "my-plugin",
"version": "1.0.0",
"nativescript": {
"platforms": {
"ios": "^1.5.0",
"android": "~1.5.0",
}
}
This way in case the project targets android 1.5.2, the plugin can be installed, but in case it targets 1.6.0, the plugin will not be available. More information for the version ranges:
https://docs.npmjs.com/getting-started/semantic-versioning#semver-for-consumers
Breaking change
In case we implement this idea, all plugins, which currently has nativescript key inside their package.json, will not work, as the values: "1.5.0" will mean - can work with this version only.
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza con el flujo de verificación de tns plugin add y la sección nativescript de los archivos package.json de los plugins; revisa cómo se comparan actualmente las versiones del runtime. Usa los rangos semver documentados de npm para que los valores exactos, con caret y con tilde produzcan el comportamiento de compatibilidad propuesto, y verifica con pruebas tanto las versiones del runtime compatibles como las rechazadas.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- javascript, node.js
- Área
- cli, mobile-dev
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100