Ensure lintTree results cannot clobber tests.
#7036
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Nice work, @rwjblue! Thanks for tracking this down! |
stefanpenner
approved these changes
May 10, 2017
|
|
||
| app.project.addons.push({ | ||
| lintTree(type, tree) { | ||
| return stew.map(tree, function(string) { |
There was a problem hiding this comment.
Fixed (along with a few other linting errors).
rwjblue
force-pushed
the
fix-lint-clobbering-tests
branch
from
b582bb9 to
0d4b4ec
Compare
Turbo87
approved these changes
May 11, 2017
| lintTree(type, tree) { | ||
| return stew.map(tree, string => string.toUpperCase()); | ||
| }, | ||
| }); |
There was a problem hiding this comment.
what is this doing? could use a short comment explaining it.
The prior logic resulted in the result of `lintTree` being **after** the actual processed `tests/` tree. When those trees were then passed to `MergeTrees` the `lintTree` result would clobber the normal processed `tests/` tree. In general, when a linter is actually emitting linting tests, this is fine because the files that it emits are not the same names as the original (e.g. `tests/test-helper.js` becomes `tests/test-helper.lint-test.js`), but when the `lintTree` implementation does not emit different names than the input tree the `lintTree` versions "win". In Ember CLI < 2.13, this setup still worked properly because we would fully process the result of `lintTree` through the consuming applications JS processor pipeline (e.g. babel). This _sounds_ neat but actually means that we were transpiling all of `tests/` twice. In Ember CLI 2.13 and above, we only process the result of `lintTree` for modules (not a full "transpile down to ES5"). This means that any babel processing that would have been done for `tests/` normally is thrown away when the transpiled versions are clobbered by the untranspiled `lintTree`. This change corrects the ordering of trees, so that the correctly proccessed `tests/` tree "wins" when the `lintTree` tree emits files with the same names.
rwjblue
force-pushed
the
fix-lint-clobbering-tests
branch
from
0d4b4ec to
7ac7d9f
Compare
|
Updated with more comments around the test adding a fake |
|
@homu r+ |
|
📌 Commit 7ac7d9f has been approved by |
homu
added a commit
that referenced
this pull request
May 11, 2017
Ensure `lintTree` results cannot clobber tests. The prior logic resulted in the result of `lintTree` being **after** the actual processed `tests/` tree. When those trees were then passed to `MergeTrees` the `lintTree` result would clobber the normal processed `tests/` tree. In general, when a linter is actually emitting linting tests, this is fine because the files that it emits are not the same names as the original (e.g. `tests/test-helper.js` becomes `tests/test-helper.lint-test.js`), but when the `lintTree` implementation does not emit different names than the input tree the `lintTree` versions "win". In Ember CLI < 2.13, this setup still worked properly because we would fully process the result of `lintTree` through the consuming applications JS processor pipeline (e.g. babel). This _sounds_ neat but actually means that we were transpiling all of `tests/` twice. In Ember CLI 2.13 and above, we only process the result of `lintTree` for modules (not a full "transpile down to ES5"). This means that any babel processing that would have been done for `tests/` normally is thrown away when the transpiled versions are clobbered by the untranspiled `lintTree`. This change corrects the ordering of trees, so that the correctly proccessed `tests/` tree "wins" when the `lintTree` tree emits files with the same names.
|
☀️ Test successful - status |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The prior logic resulted in the result of
lintTreebeing after the actual processedtests/tree. When those trees were then passed toMergeTreesthelintTreeresult would clobber the normal processedtests/tree. In general, when a linter is actually emitting linting tests, this is fine because the files that it emits are not the same names as the original (e.g.tests/test-helper.jsbecomestests/test-helper.lint-test.js), but when thelintTreeimplementation does not emit different names than the input tree thelintTreeversions "win".In Ember CLI < 2.13, this setup still worked properly because we would fully process the result of
lintTreethrough the consuming applications JS processor pipeline (e.g. babel). This sounds neat but actually means that we were transpiling all oftests/twice.In Ember CLI 2.13 and above, we only process the result of
lintTreefor modules (not a full "transpile down to ES5"). This means that any babel processing that would have been done fortests/normally is thrown away when the transpiled versions are clobbered by the untranspiledlintTree.This change corrects the ordering of trees, so that the correctly proccessed
tests/tree "wins" when thelintTreetree emits files with the same names.