Question
Cannot find module error in PureScript module resolver
Rey Moss
0 reputation · 10 Jun 2025, 19:41 UTC
137.7K views
Loading…
0 reputation · 10 Jun 2025, 19:41 UTC
PureScript’s compiler emits the documented error Cannot find module when a module import cannot be resolved. This error is the primary failure signal for missing modules and is tightly coupled to the module resolver’s behavior. In contrast, the standard library’s Effect monad offers throwError via Control.Monad.Error.Class, but it lacks a unified Error type. Consequently, error propagation across different monads and libraries is inconsistent, and pure contexts cannot safely express recoverable failures. The community has debated whether to introduce a dedicated Error type into Effect to unify error handling and enable throwError in pure contexts. This decision remains unresolved, with potential implications for backward compatibility, type inference, and runtime performance.
Questions for consideration:
Error type to Effect?throwError be implemented to work in purely functional contexts without compromising existing code?The PureScript compiler emits Cannot find module when it cannot locate a source file that matches an import declaration during module resolution.
purescriptpurs (or via spago/purs.yaml).spago, ensure the directory is listed under sources in spago.dhall or that the module is part of a package declared in packages.dhall.purs compile directly, confirm the --src argument includes the directory.spago build or purs compile ...) to verify the error disappears.If the error persists after these checks, provide the exact import statement and the contents of your source‑path configuration (e.g., spago.dhall or purs.yaml) for further diagnosis.
Use comments to ask for clarification. Post a solution as an answer.
5,940 reputation · 11 Jun 2025, 01:39 UTC
A critical distinction to maintain in this discussion is the difference between Effect.Exception and the MonadError interface. Currently, Effect handles synchronous runtime exceptions (like those from the JavaScript engine) via Effect.Exception, which are essentially untyped and dynamic.
If a unified Error type were introduced to Effect to support throwError, it would likely shift the paradigm toward explicit type-level error tracking. For those currently managing recoverable failures, the standard approach remains wrapping Effect in ExceptT. This allows for a specific error type e while keeping the underlying side effects in Effect:
type AppStack e a = ExceptT e Effect aIntegrating this directly into Effect would require a decision on whether the new Error type should be a sum type of all possible failures or a generic parameter, the latter of which would significantly alter type signatures across the existing ecosystem.