Use in-repo addon's "root" property for includes location#290
Use in-repo addon's "root" property for includes location#290rwjblue merged 19 commits intoember-cli-code-coverage:masterfrom
Conversation
# Conflicts: # .gitignore # index.js
| typeof addon.root === 'string' | ||
| ? addon.root |
There was a problem hiding this comment.
Hmm, why would addon.root not be present? I would think it always would...
| let addonDir = | ||
| typeof addon.root === 'string' | ||
| ? addon.root | ||
| : path.join(this.project.root, 'lib', addon.name); |
There was a problem hiding this comment.
I agree, this seems super odd / not good. Assuming that an addon is in lib/some-name is definitely broken.
|
OK, landed #289 so this is ready for a rebase. Note the testing system has changed a bit (not using |
…e-coverage � Conflicts: � .gitignore
…overage into in-repo-addon-paths � Conflicts: � .gitignore
|
Done, and might I add a very pleasant evolution to the testing story with #289. The hesitance of touching anything |
|
Thank you @mdeanjones! |
| const fs = require('fs-extra'); | ||
| const fixturify = require('fixturify'); | ||
|
|
||
| class InRepoAddon { |
There was a problem hiding this comment.
we don't need this file anymore, right?
|
I have a question on how to exclude an in-repo-addon introduced into the coverage report by this PR. We have a folder structure like And in our-app's package.json we specify the in-repo-addon with How can I exclude this in-repo-addon from the coverage report? I've tried even |
…code-coverage#290) Co-authored-by: Jones, Michael Dean (Contractor) <MDJONES@associates.nsf.gov>
…code-coverage#290) Co-authored-by: Jones, Michael Dean (Contractor) <MDJONES@associates.nsf.gov>
…code-coverage#290) Co-authored-by: Jones, Michael Dean (Contractor) <MDJONES@associates.nsf.gov>
…code-coverage#290) Co-authored-by: Jones, Michael Dean (Contractor) <MDJONES@associates.nsf.gov>
The goal is to instrument in-repo addons that don't reside directly within
/libby using the addon's root property, if available.Given how long the current implementation has been around I think I might be missing some important context that makes this less viable than a quick glance would suggest.