package dunolint
Install
dune-project
Dependency
Authors
Maintainers
Sources
sha256=1b064927c9e1ef5352a1886ae34a206fef0ce6a913c19a77b0162acc108e0e50
sha512=6cbc08ba318bef6584d15a4491e3dde1bf436109ce0f8b7c400a9f91bbcee64c5785bc924df11eafe98243ec2f188a7f92c58c5062729f3e2af1e9977f1a5e67
doc/dunolint.dunolint_engine/Dunolint_engine/index.html
Module Dunolint_engineSource
Cache for loaded configs to avoid re-parsing the same file multiple times.
Auto-discovery and accumulation of contextual information during tree traversal.
Context building
Build a context for a given file path by auto-discovering and loading configs from parent directories, and applying the engine's root configs.
This is useful for tools that need to lint individual files without performing a full directory traversal via visit.
path is the relative path to the file for which to build the context.
The function returns a context containing:
- The engine's root configs (specified at engine creation), which serve as base defaults
- All configs auto-discovered from the workspace root down to and including the directory containing the file, which take precedence over root configs
Execution control
While we visit the repository, we may decide what to do at each step of the iteration.
val visit :
?autoload_config:Base.bool ->
?below:Fpath_base.Relative_path.t ->
t ->
f:
(context:Context.t ->
parent_dir:Fpath_base.Relative_path.t ->
subdirectories:Base.string Base.list ->
files:Base.string Base.list ->
Visitor_decision.t) ->
Base.unitVisit the directory tree.
parent_dir contains the complete relative path to the cwd from which the command originated, which should be assumed is the dune workspace root.
subdirectories and files are the base names of the contents of the parent directory currently being visited.
autoload_config controls whether to automatically discover and load config files during traversal. Defaults to true.
root_configs is a list of base default configs applied with lowest precedence, overridden by any auto-discovered configs. Defaults to the empty list.
context contains the accumulated configuration context for the current directory being visited.
If you want to visit only a subtree of the workspace, you may provide below, which must be a relative path to a subdirectory of the cwd provided for creating t.
Lint
val lint_dune_file :
?with_linter:(Dune_linter.t -> Base.unit) ->
t ->
path:Fpath_base.Relative_path.t ->
f:(Dune_linter.Stanza.t Dunolinter.Stanza.t -> Base.unit) ->
Base.unitval lint_dune_project_file :
?with_linter:(Dune_project_linter.t -> Base.unit) ->
t ->
path:Fpath_base.Relative_path.t ->
f:(Dune_project_linter.Stanza.t Dunolinter.Stanza.t -> Base.unit) ->
Base.unitval lint_file :
?autoformat_file:(new_contents:Base.string -> Base.string) ->
?create_file:(Base.unit -> Base.string) ->
?rewrite_file:(previous_contents:Base.string -> Base.string) ->
t ->
path:Fpath_base.Relative_path.t ->
Base.unitSpawn a dune format-dune-file on the new linted contents before materializing into a file. Exposed if you need to write your own linters on files that are supported by the formatter shipped with dune.
val run :
?root_configs:Dunolint.Config.t Base.list ->
running_mode:Running_mode.t ->
(t -> 'a) ->
'aThis calls f once, registers all requests enqueued during the execution of f, and then depending on the running mode, either do a dry-run, or actually perform the desired transformations.
The intended use is for f to contain one or several calls to a function that uses t to perform some dunolint linting, such as visit, lint_dune_file, etc.
This is a convenience wrapper around create, calling f, and materialize. The root_configs and running_mode parameters are forwarded to create.
In addition to enqueuing debug messages and errors, this function outputs messages regarding I/O actions executed during linting. These messages are produced onto stdout.
Step by step API
val create :
?root_configs:Dunolint.Config.t Base.list ->
running_mode:Running_mode.t ->
Base.unit ->
tCreate a new linting engine.
The root_configs parameter allows specifying configs that will be included in the context passed to the visit callback. These configs are treated as if they were located at the workspace root.
The running_mode determines whether changes are applied (Force_yes), previewed (Dry_run), interactively confirmed (Interactive), or checked without modification (Check).
Apply all the changes that have been saved into t to the file system, or merely print them if we're in dry-run mode.