In this PR I first added a failing test to confirm this issue. Then I tried diving into the code to see if I could fix it, which I eventually could. I've tested this with our codebase and all our files showed up correctly again 🙌 I'm not too sure if this is the right way to fix it, so I'm open for suggestions.

First I generated the changes in the snapshot by moving the added util to addon and re-exporting it in app. Then I moved it back from addon to app and manually adapted the snapshot. So, I expect this test to pass when the issue is fixed, and otherwise it will probably require a little tweak to get it working. Edit: it did require a small tweak, as I was missing the two re-exports that had no effect on the coverage in the test. The rest of the initial failing test was working as I expected it to.

If I understand correctly, the coverage is reported for files like app-namespace/components/..., in-repo-addon/components/..., paths that are then converted into app/components and lib/in-repo-addon/addon/components respectively (assuming that the in-repo addon is in lib/in-repo-addon). For the app files in those addons though, the initial path is also app-namespace/components/..., so then there is no trivial mapping to the addon's app directory possible. In the end I got it working by checking if the file exists in the app-namespace's app, and if not, it has to come from an addon. It can still come from another addon though, so then I checked per in-repo addon whether the file exists there or not. If it does exist, we know that the path should be changed to the addon's path.

This approach does work for our codebase and in the tests and I also found something else it covers now as well. In the in-repo-addon test the my-app-with-in-repo-addon/lib/my-in-repo-addon/app/services/my-service.js file isn't covered because of app/services/my-service.js, so that's a nice bonus I'd say :).