Error with analyzer.ts when expanding exports from *

[maneetgoyal]

Error log:

ec: $ node scripts/find-dead-code.js
ec: /Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/analyzer.js:91
ec:             Object.keys(exportMap[ex.slice(2)].exports)
ec:                                                ^
ec: TypeError: Cannot read property 'exports' of undefined
ec:     at /Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/analyzer.js:91:48
ec:     at Array.forEach (<anonymous>)
ec:     at /Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/analyzer.js:87:14
ec:     at Array.forEach (<anonymous>)
ec:     at expandExportFromStar (/Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/analyzer.js:83:11)
pec:     at Object.default (/Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/analyzer.js:131:5)
ec:     at /Users/maneet/Documents/XYZ/node_modules/ts-unused-exports/lib/app.js:36:30
ec:     at findUnusedExports (/Users/maneet/Documents/XYZ/support/find-unused-exports.js:35:18)
ec:     at Object.<anonymous> (/Users/maneet/Documents/XYZ/packages/arcgis-charts-spec/scripts/find-dead-code.js:5:1)
ec:     at Module._compile (internal/modules/cjs/loader.js:959:30)
ec: error Command failed with exit code 1.
ec: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Upon putting console.log in the analyzer script:

var expandExportFromStar = function (files, exportMap) {
    files.forEach(function (file) {
        var fileExports = exportMap[file.path];
        file.exports
            .filter(function (ex) { return ex.startsWith('*:'); })
            .forEach(function (ex) {
            delete fileExports.exports[ex];
            console.log(exportMap);
            console.log(ex.slice(2));
            Object.keys(exportMap[ex.slice(2)].exports)
                .filter(function (e) { return e != 'default'; })
                .forEach(function (key) {
                if (!fileExports.exports[key]) {
                    var export1 = exportMap[ex.slice(2)].exports[key];
                    fileExports.exports[key] = {
                        usageCount: 0,
                        location: export1.location,
                    };
                }
                fileExports.exports[key].usageCount = 0;
            });
        });
    });
};

I got:

ec: {
ec:   src: {
ec:     exports: { '*:src/data-source': [Object] },
ec:     path: '/Users/maneet/Documents/XYZ/packages/ec/src/index.ts'
ec:   }
ec: }
ec: src/web-chart

Looks like the analyzer is expecting the exportMap is a different format.

[maneetgoyal]

Here's my TSConfig:

{
  "compilerOptions": {
    "outDir": "./dist/ts-schema",
    "noImplicitThis": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noImplicitReturns": true,
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "declaration": true,
    "sourceMap": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "module": "ES6",
    "target": "ES6",
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "keyofStringsOnly": true,
    "jsx": "react",
    "jsxFactory": "h",
    "importHelpers": true,
    "lib": ["DOM", "ES6", "DOM.Iterable", "ScriptHost", "ES2019.Array"]
  },
  "files": ["./src/index.ts"]
}

And index.ts:

export * from "./web-chart";
export * from "./data-source";

[mrseanryan]

@maneetgoyal thank you for finding this!

Hope to have a patch ready shortly

Sean

[mrseanryan]

• add test for export from a directory, implicitly picking up index.ts

[mrseanryan]

@maneetgoyal I cannot reproduce this issue.

I have a patch that should prevent the error - but you may then have some code that is not analysed.

If you have the time, it would great to have a complete example, with the TypeScript source code.

For an example, please see the issue #123

[mrseanryan]

(related) index.ts files generally tend to have false positives, for example when they are used in a library.
When I use ts-unused-exports I often exclude index.ts files from the report, with command line option: --excludePathsFromReport=index.ts

[maneetgoyal]

Hi @mrseanryan, thanks a ton for looking into this. I'll try the updated version. And get back. Will try to have a demo TS project too for reproducing if needed.

However, ignoring index.ts doesn't look a good workaround for my use-case. Here's my folder structure:

src

• index.ts
• xyz.ts
• tool1
  • index.ts
  • xyz.ts
• tool2
  • index.ts
  • xyz.ts

All the core business logic is in **/index.ts files. So I guess the majority of the codebase would be skipped using --excludePathsFromReport=index.ts.

[mrseanryan]

I see ... let me know how it goes!

[maneetgoyal]

Hi @mrseanryan,

I gave it a try. Ran into the following difficulties:

1. Wanted to run the tool on all files in the project but it seem like I need to specify each of the files in the CLI to run it (very tedious). If the CLI accepted a glob pattern, like, src/**/*.ts, it would have made it very easy to do it. Is there already such a way that this tool supports and I just missed it?

2. You mentioned about the possibility of false positives in dealing with index.ts files. Why is it the case? Since I had tens of index.ts files to run the tool on, I could not verify if it was really leading to any false positive error. It also made me less confident to continue using the tool. Once I understand the cause of false positives, my opinion can clearly change so thought of reaching out to you.

Lastly, in the concerned project we already have a linting system in place. After spending a good amount of time on making this tool work, I decided to go with using this approach. The best benefit of it was that linter check alone was able to identify unused exports and a lot of configuration and setting up of new CLI commands was avoided. Now I am just very much looking forward to a fix for #19. That will be a great feature to have.

[mrseanryan]

hi @maneetgoyal

1. To run for all files, you should not need to do anything special - just point to the tsconfig.json file.

example: ./node_modules/.bin/ts-unused-exports path/to/tsconfig.json

2. In the main project I work on, we have many index files, and they do tend to export types that are not necessarily used. So I tend to exclude the index.ts file from the report.

That's good if you found another approach that works ...

In my opinion #19 is not really just a fix, it could be a whole rewrite of the project ...

[maneetgoyal]

Hi @mrseanryan,

Thanks for the follow up. Truly appreciate it :)

To run for all files, you should not need to do anything special - just point to the tsconfig.json file.

Initially, when I started working with this tool, I also came across:

"Note that if ts-unused-exports is called without files, the files will be read from the tsconfig's files or include key which must be present. If called with files, then those file paths should be relative to the tsconfig.json, just like you would specify them in your tsconfig's files key."

But in my tsconfig.json, the files array is: "files": ["./src/index.ts"]. So I suspected that the tool will only analyze src/index.ts. But the actual .ts files in the project in the src folder are more than that. src/index.ts looks like:

export * from "./file-a.ts";
export * from "./file-b.ts";
export * from "./file-c.ts";
export {AAA, BBB} from "./file-d.ts";

I suspected that the tsconfig.json won't analyze file-a.ts, file-b.ts, etc. but as I said I want all src/**/*.ts files to be analyzed. Are you saying, the tool will still analyze all the files?

[mrseanryan]

@maneetgoyal
With that tsconfig.json,
I would expect it to pick up whatever fields are referenced from src/index.ts.

But I would xpect also that the exported types could be flagged as unused exports,
since nothing is importing the src/index.ts

This kind of "library support" is an open issue #105

issue #30 is possibly also relevant.

[mrseanryan]

@maneetgoyal if you'd like the index.ts entry to be handled, you can give a thumbs up on #105.

And perhaps you could provide feedback when we have a fix?

[maneetgoyal]

@mrseanryan I'll go through its description and comment there soon. :)

[mrseanryan]

Locking this issue - let's use more appropriate issues (or a log a new one) instead of continuing discussions here ....