validations.adoc

Validations

Table of Contents

• Viewing All Errors and Warnings
• Suppress warning 205
• Marking a Brick as Necessary to Suppress Warning 207
• Workspace Structure Reflects Error 111

Each time you execute the check, info, or test command, your workspace is validated.

For a list of validations, see the check command. You can show the same help at your terminal via:

poly help check

The check command returns a non-zero exit code on errors only (not warnings). See check for details.

The test command fails fast on any check errors. Warnings do not affect test outcome.

The info command shows errors and warnings, but they do not affect its exit code.

Tip	By default, check only runs against projects under the projects directory. Specify the :dev argument, and poly will also check your development project.

Viewing All Errors and Warnings

The poly tool stores all errors and warnings in the workspace structure; you can list them via the ws command:

poly ws get:messages

An example output:

If your workspace doesn’t have any active warnings or errors, you will see an empty result:

[]

Suppress warning 205

While migrating a codebase to a Polylith workspace, you may want to temporarily ignore warning 205, which indicates that a non-top namespace has been found in the workspace.

If you want to turn off validation for all components, update workspace.edn as follows:

{...
 :validations {:disable [{:warning 205}]}
...}

The most common is probably that you want to suppress the warning for a limited number of bricks:

{...
 :validations {:disable [{:warning 205, :bricks ["database" "invoice" ]}]}
...}

Only warning 205 can be turned off via the :validations key, for now.

Marking a Brick as Necessary to Suppress Warning 207

The check command generates a Warning 207 - Unnecessary components were found in project when it finds components unused by any bricks in a project.

Suppose you get warning 207 for a project but know the component is needed (e.g., it is used dynamically but not explicitly called). In that case, you can suppress the warning by specifying that it is :necessary to the project in your workspace.edn:

{...
 :projects {"poly" {:alias "poly"
                    :necessary ["api" "clojure-test-test-runner"] ;; (1)
                    :test {:setup-fn project.poly.hto/activate!}}
            "polyx" {:alias "polyx" :test [] :necessary ["clojure-test-test-runner"]} ;; (1)
            "development" {:alias "dev"}}
...}

1. Example usages from the poly tool itself

Workspace Structure Reflects Error 111

If poly finds that a .clj, .cljc, or .cljs source file is unreadable, you will see Error 111: Unreadable namespace.

Let’s explore this error with our example tutorial workspace. The example workspace source is here if you have not been following along.

Note	If you follow along, remember to revert your changes to your example workspace afterward.

Comment out the se.example.user.core namespace declaration in the user component:

./components/user/src/se/example/user/core.clj

;(ns se.example.user.core) ;; (1)

(defn hello [name]
  (str "Hello " name "!!"))

1. Comment this line out

Run:

poly check

You should see this error:

Have a look at the namespace with the ws command:

poly ws get:components:user:namespaces:src:core

Notice that poly has marked it as invalid:

{:file-path "components/user/src/se/example/user/core.clj",
 :imports [],
 :is-invalid true, ;; (1)
 :name "core",
 :namespace ""}

1. Marked as invalid