Right now, without pods enabled, if I have a tree folder like that:

/components
├── first-component.js
└── /custom-folder
    ├── second-component.js
    └── third-component.js

Ember resolve second-component & third-component without the custom-folder prefix. which means that in template file you can call them like that:

{{!-- some random .hbs template --}}
{{second-component}}

In the _mapComponents function it is assumed that it's a flat components hierarchy.

So even if second-component is used, the addon will look for a component named custom-folder/second-component

The function mapComponents in lib/analyzer.js is called only with app/components which means that components that only have a template won't be indexed. So the same mapComponents function should also be called with app/templates/components I guess.

These come up as unused:

{{~project-bbl bbl=bbl~}}

See the syntax here: tildeio/htmlbars#20

Reading through the code, one can see in the lib/analyzer.js file in the mapComponents function:

let recognizer = config.usePods || config.useModuleUnification ? '/component.js' : '.js';

if (filename.includes(recognizer)) {

In the case when neither pods, nor MU is used, a file extension of js is expected. This won't work correctly for .coffee and .ts files.

Would be nice to support wildcards also for the ignore option. It seems this is currently only checking for a strict match: https://github.com/vastec/ember-unused-components/blob/master/lib/analyser.js#L379

I'm working on a project with many dependencies—some of which are internal addons containing shared components used within the company. I'm in the process of trying to determine which of these addons can be cut out from a project (as in: "does this parent project ever call a component within this addon?")

ember-unused-components --occurrences is wonderful, and I'd love to know if there's a way to get it to list components that come from addons, too?

Hi,
I've noticed that there hasn't been much work on this addon in awhile. Maybe you should consider letting someone in the ember-community adopt it: https://github.com/adopted-ember-addons/program-guidelines/blob/master/README.md

As a maintainer of an ember application, I really like this addon and think it should live on!

As I see, there is some related cases covered by https://github.com/lifeart/ember-meta-explorer any inputs I can help?

Hi,

Just trying out this neat addon and so far all I can get out of it are zeros!

The app has ~100 components under ./app/components, which use the pods structure. The rest of the app uses the classic layout for routes, controllers, and so on, i.e. it only use the pod structure for components.

config/environment.js sets podModulePrefix to an empty string.

Running yarn ember-unused-components --pods gives:

 No. of components: 0
 No. of unused components: 0 

 Congratulations! No unused components found in your project.

I'll try to find some time to troubleshoot the problem next week. My understanding is that this is expected tot be supported already, is that correct?

Many thanks.

Great addon, thanks! I would like my build to fail when there are unused components. So perhaps generate a test (like many other addons do) so that running ember test will fail?

It's great to know the total components and total unused components. My team found this addon while looking for a solution to count the components in our app in an effort to identify components that are reused (vs unused).

Could the --stats output include the count of components that are reused?

 No. of components: 100
 No. of unused components: 5 (5.00%)
 No. of reused components: 25 (25.00%)

I noticed the option for --occurrences lists where the components are found, perhaps components that are found more than once could be considered "reused" and a statistic for reused could be incremented.

What I had in mind is an option for --counts that leverages --occurrences behavior but only lists the components and the number of time that the component is used.

Hi I just discover your repository while trying to write similar addon and it's a great discovery!

You can find my experimental addon here
I took a different approach I've written all the main part in a bash script (I don't care about OS compatibility for the moment).

I've discover that your addon miss some cases like inheritance, for example.

// components/concrete.js
import AbstractComponent from 'my-app/components/abstract';

export default AbstractComponent.extend({
   // do stuff
})

or some addons like ember-light-table declare stuff like:

// components/my-table.js
import { computed } from '@ember/object';
import Table from 'ember-light-table';

export default Ember.Component.extend({
  model: null,

  columns: computed(function() {
    return [{
      label: 'Avatar',
      valuePath: 'avatar',
      width: '60px',
      sortable: false,
      cellComponent: 'user-avatar' // <----- here is the issue
    }];
  }),

  table: computed('model', function() {
   return new Table(this.get('columns'), this.get('model'));
  })
});

So I made a PR to fix that -> #2

I've also notice that you don't provide any cleanup option to directly remove components from the addon.
Something like ember unused:components --cleanup.

I have achieved this in my project with dirty exec
Do you know a way to call directly another ember command without spawning another process?

Hi, thank you for building and share this script!

I wanted to note a few false positives I found running this on my app. These cases require advanced analysis and perhaps @lifeart's ember-meta-explorer better suits finding those occurrences. Dyfactor could also apply here.

1. we invoke a component name as an argument to an action

{{action "someAction" "my-component-form" bubbles=false}} 

2. we have a component only used in tests (very lame, I know 😄).
3. We have multiple {{component (concat "thing-" someVariable)}}

There are a couple others, mostly around more complex {{component helper usage.
To me, a good solution would just be indicating possible false positives around any {{component usage. Perhaps even more naive checks for the string of a component name used by helpers or passed as properties to a component.

Right now the addon only handle components but we can imagine other algorithm to find unused routes, views, partials...

The addon can be renamed ember-unused and can provides multiple commands like ember unused:views.

Is it something you have in mind for futur releases?

VSCode addon: https://marketplace.visualstudio.com/items?itemName=lifeart.vscode-ember-unstable

Usecase: https://code.visualstudio.com/api/language-extensions/programmatic-language-features#find-all-references-to-a-symbol

context: NullVoxPopuli/coc-ember#9

Fild all references to a symbol

proposed api:

"ember-language-server": {
    "entry": "./lib/langserver",
    "referencesProvider": true
}

module.exports.onReference = async function(projectRoot, { itemType: 'COMPONENT', itemName: 'normalized/component/name' }) {
        return [
         { path: "app/templates/route-name/route.hbs", position: { line: 0, character: 12 } },
         { path: "app/templates/route-name/route.hbs", position: { line: 10, character: 12 } }
        ];
    }
}

//cc @NullVoxPopuli

Since version 3.7, Ember supports angle bracket components. When running this addon, it does not recognize the usage of angle bracket components.

I don't have an app directory :(

$ ember unused:components
Searching for unused components:
ENOENT: no such file or directory, scandir './app/components'

Consider these:

➜  ember-unused-components git:(master) ./index.js --path="test-apps/ember_3_10_mu/" --stats
Can't find Ember config. Are you sure you are running this in root directory?

☝️ That's ok. The path was wrong. The error was thrown.
👇 That's not ok. A small change in path with / at the beginning but not at the end and it crashes:

➜  ember-unused-components git:(master) ./index.js --path="/test-apps/ember_3_10_mu" --stats
[1/3] 🗺️  Mapping the project...
fs.js:114
    throw err;
    ^

Error: ENOENT: no such file or directory, scandir './/test-apps/ember_3_10_musrc/ui/components'
    at Object.readdirSync (fs.js:790:3)
    at Object.mapComponents (/Users/tomek/Projects/my/ember-unused-components/lib/analyser.js:231:20)
    at main (/Users/tomek/Projects/my/ember-unused-components/index.js:36:12)
    at Object.<anonymous> (/Users/tomek/Projects/my/ember-unused-components/index.js:46:1)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:829:12)

Seems there is a mismatch of function params:

• https://github.com/vastec/ember-unused-components/blob/master/lib/analyser.js#L359
• https://github.com/vastec/ember-unused-components/blob/master/lib/analyser.js#L378

But also when I change the invocation to pass config, the filename is something like ./app/..., so does not really match what the documentation says.

Whitelist files that are needed for this library to operate. The current size of the package is too big to what it does. Mostly because of including tests files and test applications (a few Ember apps).

➜  ember-unused-components git:(master) npm pack --dry-run

npm notice === Tarball Details ===
npm notice name:          ember-unused-components
npm notice version:       1.0.4
npm notice filename:      ember-unused-components-1.0.4.tgz
npm notice package size:  789.0 kB
npm notice unpacked size: 2.2 MB
npm notice total files:   422

Hi! It would be nice if ember-unused-components also supports the nested component structure.

Atm, even though used, this component is flagged as unused:

- app/components/foo-bar/index.js
- app/components/foo-bar/index.hbs

It seems like we can achieve this by updating the objectName function to also strip index.js and index.hbs.

If you can also tell me what else is needed testing wise, I could probably make a PR for this.