This repository has been archived by the owner on Dec 31, 2019. It is now read-only.
Reverting config parsing changes to preserve .istanbul.yml functionality #84
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commit fb4dea9 introduced a backwards-incompatible change, breaking the expectations that values set in the .istanbul.yml config file would be used if the corresponding parameter wasn't set to override it. For instance, running with isparta@3.1.0 with this
.istanbul.yml
(notice the non-default values):and the following command (executed via npm):
Would result with the following output during coverage:
However, each version since the aforementioned change disregards certain values in the
.istanbul.yaml
, specificallyroot
,include-all-sources
, anddefault-excludes
, resulting in the following:Turns out it has to do with how the arguments are being passed to Istanbul's configuration functions. For instance,
mergeObjects
overwrites template values with whatever is being passed in as the override. You'll notice this works for some of the other default parameter values set up here because they're empty arrays (whichmergeObjects
discards in favor of what has been loaded from the config file).It's probably worth revisiting how to make this configuration more robust, but I wanted to offer a quick solution to reestablish this functionality quickly, as I (and perhaps others) are going to have to stay pinned to
3.1.0
for the time being.