EslintValidationFilter can only handle one:* broccoli nodes, but part of the given input pipeline is a many:* node. (broccoli-merge-trees is an example of a many:* node) Please perform many:* operations after linting.

[systembugtj]

Not sure what's that meaning, we do use the merges tree to merge some code in.

But not sure what's exactly the meaning of this message.

[alexlafroscia]

Hey @systembugtj, can you attach your Broccoli config in here so I can take a look at it?

This issue stems from the way that broccoli-lint-eslint functions; it's the one that does not allow many:* nodes. For people using this addon the recommended way, this shouldn't be an issue, but I'm really interested to see what you're doing in hopes that we can make more complex setups work out-of-the-box as well.

[runspired]

Hit this tonight. The primary issue here is that this prevents you from ever being able to build a complex app tree.

In my case, I have a tree that is a single file being added to the app tree. However, this single file tree is the product of a complex build step that merges together many available addon trees. Because there is a mergeTree in this graph at all, this error is thrown.

[akondo06]

Hi, I have encountered the same issue when using mergeTrees. In my ember-cli-build file I have 2 EmberApp instances: one being the app folder and second app + admin folder (more info here ember-cli/ember-cli#6887). Any update on the issue or a workaround?

[pzuraq]

Ran into this today as well, my use case was trying to automatically generate some tests in a different language (TypeScript) to validate that my library works with TS (it uses decorators, they compile differently, etc.). It's definitely an advanced use case, but is there a compelling reason to handle many trees?

[Turbo87]

@pzuraq if I understand correctly it is currently a limitation of broccoli-lint-eslint, so the issue should actually be opened over there instead. That said, PRs to fix it are certainly welcome 😉

[pzuraq]

Looks like there's an open PR already: ember-cli/broccoli-lint-eslint#122

[willviles]

This seems to be a bit of a blocking issue when trying to work with Module Unification's src tree.

app.trees.src = new MergeTrees([app.trees.src, newTree])

Errors with:

EslintValidationFilter can only handle one:* broccoli nodes, but part of the given input pipeline is a many:* node. (broccoli-merge-trees is an example of a many:* node) Please perform many:* operations after linting.

Is there any workaround until ember-cli/broccoli-lint-eslint#122 is merged?

[rwjblue]

@willviles - I am (personally) of the mind to simply remove ember-cli-eslint from apps/addons, and use eslint directly in CI from the yarn lint:js script. In editor feedback (via eslint integration) is much faster/better than the generated tests, and ultimately not including ember-cli-eslint in the app means builds/rebuilds are a bit faster...

[gossi]

@willviles it doesn't work to merge trees in blank ember-cli-build.js. You mentioned app.trees.src = new MergeTree(...); is the error to that.

A workaround - which nobody should really do - is to extend the getSrc method and funnel your stuff in there, see my example at ember-cli/ember-cli#7862

[houfeng0923]

execute me, any body here ?

and , why app.trees.app not allow MergeTrees ?

recently , i have to build a complex project with two app* folders ,
and how to pass eslint validation?

[rwjblue]

execute me, any body here ?

yep 😸

and , why app.trees.app not allow MergeTrees ?

Because, due to the way the build system works, there is no way to determine the original on-disk path to a file. The original on disk path is really important for running eslint because there are many different ways to configure files in eslint (e.g. combining config files through a file heirarchy, many different extensions of config file, etc).

recently , i have to build a complex project with two app* folders ,and how to pass eslint validation?

Good news, the latest ember-cli blueprints avoid this issue entirely. 🎉

I'd suggest you (and anyone else with this issue) review the changes for [email protected], and use eslint directly. See this commit for a nice summary of the changes to the blueprint.

[rwjblue]

Given that our recommendation at this point is to not use this library, I'm going to close this issue...