BadgeApp

Qualité 13/13 ●

Système de construction opérationnel

Criterion [build]
Atteint

Non atteint

N/A

?

Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. ^[build]
Un système de construction détermine quelles actions doivent se produire pour reconstruire le logiciel (et dans quel ordre), puis exécute ces étapes. Par exemple, il peut invoquer un compilateur pour compiler le code source. Si un exécutable est créé à partir du code source, il doit être possible de modifier le code source du projet, puis de générer un exécutable mis à jour avec ces modifications. Si le logiciel produit par le projet dépend de bibliothèques externes, le système de construction n'a pas besoin de construire ces bibliothèques externes. S'il n'est pas nécessaire de construire quoi que ce soit pour utiliser le logiciel après la modification de son code source, sélectionnez « non applicable » (N/A).

https://github.com/marko-js/marko/blob/main/package.json contains a script build
Criterion [build_common_tools]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. ^{[build_common_tools]}
Par exemple, Maven, Ant, cmake, autotools, make, rake (Ruby) ou devtools (R).
All the tools used in the build scripts at https://github.com/marko-js/marko/blob/main/package.json are well known:
```
"build": "npm exec --ws -- babel ./src --out-dir ./dist --delete-dir-on-start --copy-files --config-file ../../babel.config.js --env-name=production && npm run build:types",
"build:types": "node scripts/types-babel-types.mjs > packages/compiler/dist/types.d.ts && node scripts/types-babel-traverse.js > packages/compiler/dist/traverse.d.ts",
"publish": "ENTRY=main:npm npm run set-entry && npm run build && changeset publish && ENTRY=main:dev npm run set-entry && npm ci",
```
Criterion [build_floss_tools]
Atteint

Non atteint

N/A

?

Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. ^{[build_floss_tools]}

Tools in build script -

npm: Artistic License 2.0 babel: MIT license node: MIT license changeset: MIT license
Suite de tests automatisée

Criterion [test]
Atteint

Non atteint

?

Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). Le projet DOIT clairement montrer ou documenter comment exécuter la ou les suites de tests (par exemple, via un script d'intégration continue (CI) ou via la documentation dans des fichiers tels que BUILD.md, README.md ou CONTRIBUTING.md). ^[test]
Le projet PEUT utiliser plusieurs suites de tests automatisées (par exemple, une qui s'exécute rapidement, par rapport à une autre qui est plus approfondie, mais nécessite un équipement spécial). De nombreuses plate-formes de tests et environnements de tests sont disponibles, tels que Selenium (automatisation de navigateur Web), Junit (JVM, Java), RUnit (R), testthat (R).

Unit tests use Mocha.

Criterion [test_invocation]
Atteint

Non atteint

?

Une suite de tests DEVRAIT être invocable d'une manière standard pour ce langage. ^{[test_invocation]}
Par exemple, « make check », « mvn test » ou « rake test » (Ruby).

npm run test

Criterion [test_most]
Atteint

Non atteint

?

Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. ^[test_most]

89.73%

File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s ---------------------------------------|---------|----------|---------|---------|------------------- All files | 89.73 | 83.34 | 86.93 | 89.93 |

Criterion [test_continuous_integration]
Atteint

Non atteint

?

Il est PROPOSÉ que le projet utilise une intégration continue (où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat). ^{[test_continuous_integration]}

Tests are run on push to the main branch. See e.g. https://github.com/marko-js/marko/actions/runs/4208297860
Nouveau test de fonctionnalité

Criterion [test_policy]
Atteint

Non atteint

?

Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. ^{[test_policy]}
Dès qu'une politique est en place, même par le bouche à oreille, qui spécifie que les développeurs devraient ajouter des tests à une suite de tests automatisée pour toute nouvelle fonctionnalité importante, sélectionnez « Atteint ».

The test coverage of 90% would be impossible if this wasn't true.

Criterion [tests_are_added]
Atteint

Non atteint

?

Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. ^{[tests_are_added]}
Les principales fonctionnalités sont généralement mentionnées dans les notes de version. La perfection n'est pas nécessaire, il suffit de prouver que les tests sont généralement ajoutés en pratique à la suite de tests automatisée lorsque de nouvelles fonctionnalités majeures sont ajoutées au logiciel produit par le projet.

The feature PR at https://github.com/marko-js/marko/pull/1836/files includes tests.
Criterion [tests_documented_added]
Atteint

Non atteint

?

Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. ^{[tests_documented_added]}
Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.
The template for "feat:" PRs has a checklist that includes a requirement that tests be added.

`Checklist:
- [ ] I have read the CONTRIBUTING document and have signed (or will sign) the CLA.
- [ ] I have updated/added documentation affected by my changes.
- [ ] I have added tests to cover my changes.`
Options d'avertissement

Criterion [warnings]
Atteint

Non atteint

N/A

?

Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. ^[warnings]
Des exemples d'options d'avertissement du compilateur incluent « -Wall » pour gcc/clang. Des exemples d'un mode de langage « sûr » incluent « use strict » en JavaScript et « use warnings » de perl5. Un outil « linter » distinct est simplement un outil qui examine le code source pour rechercher des erreurs de qualité de code ou des erreurs simples courantes. Ceux-ci sont généralement activés par le code source ou par les instructions de construction.

package.json has linting scripts:

"lint": "npm run lint:eslint && npm run lint:prettier -- -l", "lint:eslint": "eslint -f visualstudio .", "lint:prettier": "prettier \"./**/*{.ts,.js,.json,.md,.yml}\"",

Criterion [warnings_fixed]
Atteint

Non atteint

N/A

?

Le projet DOIT résoudre les avertissements. ^{[warnings_fixed]}
Ce sont les avertissements identifiés par la mise en œuvre du critère warnings. Le projet doit corriger les avertissements ou les marquer dans le code source comme faux positifs. Idéalement, il n'y aurait pas d'avertissement, mais un projet PEUT accepter certains avertissements (généralement moins de 1 avertissement pour 100 lignes ou moins de 10 avertissements).

The lint script invokes prettier to fix warnings at the level of convention.

Criterion [warnings_strict]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ que les projets soient maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. ^{[warnings_strict]}
Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

The tool used doesn't really have that feature. At least it is invoked with the -l flag to alert devs to noncormant files.

Ces données sont disponibles sous une licence Creative Commons Attribution version 3.0 ou ultérieure (CC-BY-3.0+). Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Lucas Gonze et les contributeurs du badge des meilleures pratiques de la OpenSSF.

marko

Notions de base 13/13 ●

Identification

Contenu basique du site Web du projet

Licence FLOSS

Documentation

Autre

Contrôle des modifications 9/9 ●

Dépôt source public sous contrôle de version

Numérotation unique de la version

Notes de version

Compte-rendu 8/8 ●

Procédure de signalement des bogues

Processus de signalement de vulnérabilité

Qualité 13/13 ●

Système de construction opérationnel

Suite de tests automatisée

Nouveau test de fonctionnalité

Options d'avertissement

Sécurité 14/16 ●

Connaissance du développement sécurisé

Utiliser de bonnes pratiques de base de cryptographie

Livraison sécurisée contre les attaques man-in-the-middle (MITM)

Vulnérabilités publiquement identifiées et corrigées

Autres problèmes de sécurité

Analyse 8/8 ●

Analyse statique de code

Analyse dynamique de code