This may be a known issue. If so, I think it could be documented better. I could not find a clear answer in the issue archive to match this, so, at the very least, this issue might help others who encounter the problem.

Steps to reproduce:

1. Create a .cabal for an executable.
   • Include the hs-source-dirs field mentioning the source directories with the modules.
   • Do not include the other-modules field with the modules listed.
2. Create a stack from that .cabal.
3. stack build the first time.
4. Change a module in the package.
5. stack build to rebuild.

Expected:

The project rebuilds.

Actual:

The project does not rebuild.

Discussion:

I couldn't figure out why my project wasn't rebuilding. Then, I found that if I include other-modules with a module M and update M, the project would rebuild. If I then change N, a module not listed in other-modules, the project would not rebuild.

Related:

These issues seem to be related:

• Detect when a module is compiled but not listed in the cabal file Detect when a module is compiled but not listed in the cabal file #32
• Respect TemplateHaskell addDependentFile dependency changes Respect TemplateHaskell addDependentFile dependency changes #105
• Stack not detecting changes for incremental builds Stack not detecting changes for incremental builds #481
• Stack not rebuilding Stack not rebuilding #573
• stack test not detecting changes to the test suite stack test not detecting changes to the test suite #556

From my cursory reading, it seems like this issue was supposed to be fixed in:

• Detect unlisted modules and TH dependent files Detect unlisted modules and TH dependent files (#32,#105) #734

There seems to be a currently undocumented --force-dirty flag added in 09a9fa4 to deal with this kind of issue.

I believe I did see a warning for unlisted modules (added in 31712d3?), but I wasn't sure what the warning was for. I wasn't even sure what an “unlisted module” was. Why would unlisted modules be a problem? If this issue is the reason for that warning, then the warning text could be improved.

Questions:

If this is a known issue with no fix currently planned, could it be documented better or handled by stack?

• One option would be to mention it somewhere in the guide. The “Build command” section would be a good place to start with.
• Another option would be to automate the check with stack and report it.