motoko-compiler-warnings-fixes
Fixing Motoko Compiler Warnings
How to Run the Build Check
For DFX projects:
dfx build --check 2>&1 | tee /tmp/dfx_build_output.txt
This type-checks all canisters without deploying. Redirect stderr to capture warnings. The build takes several minutes for large projects.
For MOPS packages:
find src -type f -name "*.mo" -print0 | xargs -0 -n1 $(mops toolchain bin moc) --check $(mops sources) 2>&1 | tee /tmp/moc_check_output.txt
This uses moc --check on each file individually to avoid excessive warnings. It is often faster than a full dfx build --check and is ideal for standalone Motoko packages.
More from research-ag/motoko-skills
motoko-core-code-improvements
Optional, modular cleanups and style improvements to apply on new mo:core projects (or after mo:core migration). Covers import ordering, unused import cleanup, and single‑expression return removal, with detection checks and automation recipes.
35motoko-general-style-guidelines
Load when working with contents in *.mo files
34motoko-performance-optimizations
General performance optimization techniques for Motoko. Reducing allocations, efficient Text building, fixed-width arithmetic, block processing, async patterns, and more. Load when you need to improve hot paths or reduce overhead without changing behavior.
33motoko-benchmarks-generation
How to write benchmarks in Motoko using bench‑helper. Covers project setup (mops.toml), bench file layout in bench/*.bench.mo, the Bench.Schema rows/cols model, and safe patterns for encode/decode, hashing, crypto, and allocation benches.
33motoko-dot-notation-migration
Use new dot-notation syntax in projects with mo:core dependency
33motoko-base-to-core-migration
Complete, AI-ready playbook to migrate Motoko projects from mo:base to mo:core — phases, renames, data structure changes, agent strategy, verification scripts, upgrade tests, and production rollout.
29