BadgeApp

Calidad 13/13 ●

Working build system

Criterion [build]
Met

Unmet

N/A

?

Si el software generado por el proyecto requiere ser construido para su uso, el proyecto DEBE proporcionar un sistema de compilación que pueda satisfactoriamente reconstruir automáticamente el software a partir del código fuente. ^[build]
A build system determines what actions need to occur to rebuild the software (and in what order), and then performs those steps. For example, it can invoke a compiler to compile the source code. If an executable is created from source code, it must be possible to modify the project's source code and then generate an updated executable with those modifications. If the software produced by the project depends on external libraries, the build system does not need to build those external libraries. If there is no need to build anything to use the software after its source code is modified, select "not applicable" (N/A).

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

Unmet

N/A

?

Se SUGIERE que se utilicen herramientas comunes para construir el software. ^{[build_common_tools]}
Por ejemplo: Maven, Ant, cmake, autotools, make o rake.
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]
Met

Unmet

N/A

?

El proyecto DEBERÍA ser construible usando solo herramientas FLOSS. ^{[build_floss_tools]}

Tools in build script -

npm: Artistic License 2.0 babel: MIT license node: MIT license changeset: MIT license
Automated test suite

Criterion [test]
Met

Unmet

?

The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). ^[test]
The project MAY use multiple automated test suites (e.g., one that runs quickly, vs. another that is more thorough but requires special equipment). There are many test frameworks and test support systems available, including Selenium (web browser automation), Junit (JVM, Java), RUnit (R), testthat (R).

Unit tests use Mocha.

Criterion [test_invocation]
Met

Unmet

?

Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. ^{[test_invocation]}
Ejemplos: "make check", "mvn test" o "rake test".

npm run test

Criterion [test_most]
Met

Unmet

?

It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. ^[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]
Met

Unmet

?

It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). ^{[test_continuous_integration]}

Tests are run on push to the main branch. See e.g. https://github.com/marko-js/marko/actions/runs/4208297860
New functionality testing

Criterion [test_policy]
Met

Unmet

?

The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. ^{[test_policy]}
As long as a policy is in place, even by word of mouth, that says developers should add tests to the automated test suite for major new functionality, select "Met."

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

Criterion [tests_are_added]
Met

Unmet

?

The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. ^{[tests_are_added]}
Major functionality would typically be mentioned in the release notes. Perfection is not required, merely evidence that tests are typically being added in practice to the automated test suite when new major functionality is added to the software produced by the project.

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

Unmet

?

It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. ^{[tests_documented_added]}
However, even an informal rule is acceptable as long as the tests are being added in practice.
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.`
Banderas de advertencia

Criterion [warnings]
Met

Unmet

N/A

?

The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. ^[warnings]
Examples of compiler warning flags include gcc/clang "-Wall". Examples of a "safe" language mode include JavaScript "use strict" and perl5's "use warnings". A separate "linter" tool is simply a tool that examines the source code to look for code quality errors or common simple mistakes. These are typically enabled within the source code or build instructions.

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]
Met

Unmet

N/A

?

El proyecto DEBE abordar las advertencias. ^{[warnings_fixed]}
These are the warnings identified by the implementation of the warnings criterion. The project should fix warnings or mark them in the source code as false positives. Ideally there would be no warnings, but a project MAY accept some warnings (typically less than 1 warning per 100 lines or less than 10 warnings).

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

Criterion [warnings_strict]
Met

Unmet

N/A

?

It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. ^{[warnings_strict]}
Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

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

This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Lucas Gonze and the OpenSSF Best Practices badge contributors.

marko

Basics 13/13 ●

Identification

Basic project website content

FLOSS license

Documentation

Other

Change Control 9/9 ●

Repositorio público para el control de versiones de código fuente

Numeración única de versión

Notas de lanzamiento

Informes 8/8 ●

Bug-reporting process

Proceso de informe de vulnerabilidad

Calidad 13/13 ●

Working build system

Automated test suite

New functionality testing

Banderas de advertencia

Seguridad 14/16 ●

Conocimiento de desarrollo seguro

Use buenas prácticas criptográficas

Entrega garantizada contra ataques de hombre en el medio (MITM)

Vulnerabilidades públicamente conocidas corregidas

Otros problemas de seguridad

Analysis 8/8 ●

Análisis estático de código

Dynamic code analysis