Flag to return Exit Code 0 on Warnings (Nice to Have)

[AbdullahHendy]

What

It would be nice to have a --ignore-warnings flag, or even better, something like python's ruff linter config file

Why

My clickworthy-resume dev repo has Test flow that runs using tytanic

[abdullah@abdullahs clickworthy-resume]$ tree -L 3
.
├── LICENSE
├── Makefile
├── README.md
├── src
│   ├── cover-letter.typ
│   ├── lib.typ
│   └── resume-cv.typ
├── template
│   ├── assets
│   │   └── publications.bib
│   ├── cover-letter.typ
│   ├── cv.typ
│   └── resume.typ
├── tests
│   ├── cover-letter
│   │   ├── diff
│   │   ├── out
│   │   ├── ref
│   │   └── test.typ
│   ├── cv
│   │   ├── diff
│   │   ├── out
│   │   ├── ref
│   │   └── test.typ
│   └── resume
│       ├── diff
│       ├── out
│       ├── ref
│       └── test.typ
├── thumbnail.png
└── typst.toml

17 directories, 15 files

In each test.typ, I am importing my source code using relative paths to make it easier to test without having to install the package locally every time a change is introduced. It makes sense to me for the test to import using relative paths.

Now running typst-package-check check returns a exit code (2) warning not an exit code (1) error (which is nice) but still fails

[abdullah@abdullahs clickworthy-resume]$ typst-package-check check
warning: This import should use the package specification, not a relative path.
  ┌─ tests/resume/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: This import should use the package specification, not a relative path.
  ┌─ tests/cv/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: This import should use the package specification, not a relative path.
  ┌─ tests/cover-letter/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[abdullah@abdullahs clickworthy-resume]$ echo $?
2

It would be nice to have --ignore-warnings or such to return exit code 0 for no error results.

Work Around

For now, since warning only outputs result in an exit code 2, i do typst-package-check check || [ $? -eq 2 ] which results in exit code 0

[abdullah@abdullahs clickworthy-resume]$ typst-package-check check || [ $? -eq 2 ]
warning: This import should use the package specification, not a relative path.
  ┌─ tests/resume/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: This import should use the package specification, not a relative path.
  ┌─ tests/cv/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: This import should use the package specification, not a relative path.
  ┌─ tests/cover-letter/test.typ:1:1
  │
1 │ #import "../../src/lib.typ": *
  │  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[abdullah@abdullahs clickworthy-resume]$ echo $?
0

Discussion/Opinion

Please feel free to share

• if my intuition to import relative paths in tests/ is not the best way.
• if there are better ways to go about this whole thing

[elegaanz]

This warning is a bit too aggressive in general, but the direction I would like to go to to fix this issue is to be able to disable specific warnings. Each warning (and error) would be assigned a code/identifier, here for example "typst/imports/relative" and then you would be able to disable it with --allow typst/imports/relative (or --allow 'typst/imports/*' to ignore all import-related warnings). Does that sound like a satisfying solution to you?

[AbdullahHendy]

That sounds like the more comprehensive solution similar to what ruff does (as well as things like --warnings-as-errors=<string> - Upgrades warnings to errors in clang-tidy for c/cpp) as stated in the original issue, where one can chose what categories to lint for and what to ignore:

[tool.ruff.lint]
# 1. Enable flake8-bugbear (`B`) rules, in addition to the defaults.
select = ["E4", "E7", "E9", "F", "B"]

# 2. Avoid enforcing line-length violations (`E501`)
ignore = ["E501"]

If this is too much, or simply is a long-term feature, it seems acceptable to me to have something like --allow-warnings, or the opposite, --error-on-warnings, type of logic.
This later seems quite common from my limited experience with linters and build tools in general. For example from what I can remember:

• ESLint CLI Javascript Linter has something like eslint app.js --max-warnings=0 to fail on warnings, default is -1 doesn't fail on warnings.
• Rust Clippy Linter has something like cargo clippy -- -D warnings to fail on warnings.
• The infamous gcc -Werror

I am not familiar with Rust philosophies or your vision for the tool so I am not sure if a simplified -Werror would be fine in case the other solution is not a priority for now.

tl;dr:
Your solution is good to me and reminds me of --warnings-as-errors=<string> from clang-tidy and other popular linting tools. If warnings identifiers is too much work for now, something like gcc's -Werror is fine for now and can be still used when warnings are categorized e.g. gcc's -Wpedantic -Wconversion -Wunused etc..

[Leedehai]

Hi - I also wish the GitHub action package-check that typst/packages repo uses on the PRs to ignore warnings, or allow me (as the package author) to specify in my package's code which warnings should be ignored so that the exit code is 0 :)