Manage compilation errors in shadow-cljs
When working on migrating a large Clojure and ClojureScript project from Figwheel to shadow-cljs, you might encounter numerous challenges, including outdated dependencies and differences in how JavaScript modules are imported, problems with type hinting for JavaScript variables in ClojureScript code, use of deprecated functions, such as reagent.dom/dom-node
.
These issues can disrupt the hot reload feature, requiring manual browser refreshes to view code changes.
In the midst of a complex and time-consuming migration, it's often more practical to configure the compiler to continue recompilation despite warnings, rather than halting. This approach allows you to focus on the migration without being sidetracked by every single warning.
Shadow-cljs provides the :ignore-warnings
option to support this need. By setting :ignore-warnings
to true
within the :devtools
map in your shadow-cljs.edn
configuration file, you can suppress the interruption of the recompilation process by warnings. Here's how you can modify your shadow-cljs.edn to include this option:
;; shadow-cljs configuration
{:source-paths ["src/dev" "src/main" "src/test"]
:dependencies [[]]
:dev-http {8020 "public"}
:builds {:app {:target :browser
:output-dir "public/js"
:asset-path "/js"
:modules {:main {:init-fn starter.browser/init}}
:devtools {:ignore-warnings true}}}}
With :ignore-warnings
set to true
, hot reload functionality is preserved, allowing you to see changes without manual browser refreshes. Importantly, even with warnings ignored, they will still be recorded in the terminal and browser console. This means you can continue to track and address issues systematically, without letting them interrupt the migration process.
However, it's crucial to treat this configuration as a temporary measure. Once the migration to shadow-cljs is complete and the codebase is stabilized, you should remove or disable the :ignore-warnings
option.
By re-enabling warnings, you ensure that future development adheres to best practices, and any problematic code is identified and addressed promptly. Keeping warnings enabled in the long term supports the overall health and maintainability of the project.
- Previous: Let's build a ClojureScript PWA