Running against .ts files fails with error: 'TypeError: p is not iterable' #688

danielreidwoebot · 2021-12-14T18:28:02Z

Bug Description

I'm trying to run depcheck against TypeScript code but it's failing with the error: TypeError: p is not iterable. I've tried installing with npm i -g depcheck and also npm i -g depcheck typescript.

The error was generated after running:

depcheck path/to/my/repo --json

I have tried:

depcheck path/to/my/repo --parsers="*.ts" --json

However, when I run this (^) command I get the error: Cannot read property 'split' of undefined. It does seem to be working as expected for .js files though.

Here's the stack trace for the error in the issue title.

"TypeError: p is not iterable\n    at /Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:10658:43\n    at Array.some (<anonymous>)\n    at hasPlugin (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:10654:18)\n    at validatePlugins (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:10693:7)\n    at getParser (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:15283:5)\n    at parse (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:15254:12)\n    at parseTypescript (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/dist/parser/typescript.js:17:28)\n    at async getDependencies (/Users/danielreid/.nvm/versions/node/v14.18.2/lib/node_modules/depcheck/dist/check.js:71:18)"

Versions

node -v: v14.18.2
npm -v: 6.14.15
depcheck --version: 1.4.2

The text was updated successfully, but these errors were encountered:

rumpl · 2021-12-14T18:33:24Z

Can you try with depcheck path/to/my/repo --parsers="**/*.ts:ts" --json

danielreidwoebot · 2021-12-14T18:40:52Z

depcheck path/to/my/repo --parsers="**/*.ts:ts" --json

@rumpl thanks, yeah I can see now I misunderstood the syntax for the argument. I definitely get better results when running that, but I'm still seeing errors:

"TypeError: parser is not a function\n    at getDependencies (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/dist/check.js:71:24)\n    at /Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/dist/check.js:97:32\n    at Array.map (<anonymous>)\n    at checkFile (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/dist/check.js:97:18)\n    at ReaddirpStream.<anonymous> (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/dist/check.js:126:24)\n    at ReaddirpStream.emit (events.js:314:20)\n    at addChunk (_stream_readable.js:297:12)\n    at readableAddChunk (_stream_readable.js:272:9)\n    at ReaddirpStream.Readable.push (_stream_readable.js:213:10)\n    at ReaddirpStream._read (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/readdirp/index.js:143:22)",
        "/Users/danielreid/Projects/woebot-lambdas/src/utils/npm-licenses.js": "SyntaxError: Unexpected reserved word 'package'. (129:14)\n    at Parser._raise (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:569:17)\n    at Parser.raiseWithData (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:562:17)\n    at Parser.raise (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:523:17)\n    at Parser.checkReservedWord (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:13047:12)\n    at Parser.parseIdentifierName (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:13001:12)\n    at Parser.parseIdentifier (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:12971:23)\n    at Parser.parseBindingAtom (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:11033:17)\n    at Parser.parseVarId (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:14208:20)\n    at Parser.parseVar (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:14184:12)\n    at Parser.parseVarStatement (/Users/danielreid/.nvm/versions/node/v12.22.7/lib/node_modules/depcheck/node_modules/@babel/parser/lib/index.js:14001:10)",

hedgepigdaniel · 2021-12-15T07:01:26Z

I think the problem is that this is not a valid plugin configuration:

depcheck/src/parser/typescript.js

Line 34 in 180e05a

{ pipelineOperator: { proposal: 'minimal' } },

danielreidwoebot · 2021-12-15T13:27:44Z

@hedgepigdaniel thanks, i did try your fix but I get the same error.

danielreidwoebot · 2021-12-15T15:32:41Z

@hedgepigdaniel actually, I noticed a tread outlining an issue with running with npx so I ran npm link to link your fix to the globally installed package and it seems to have worked.

I'm still seeing the error TypeError: parser is not a function but now it's only thrown for .json files:

TypeError: parser is not a function\n    
    at getDependencies (/Users/danielreid/Projects/depcheck/dist/check.js:71:24)\n    
    at /Users/danielreid/Projects/depcheck/dist/check.js:97:32\n    
    at Array.map (<anonymous>)\n    
    at checkFile (/Users/danielreid/Projects/depcheck/dist/check.js:97:18)\n    
    at ReaddirpStream.<anonymous> (/Users/danielreid/Projects/depcheck/dist/check.js:126:24)\n    
    at ReaddirpStream.emit (events.js:314:20)\n    
    at addChunk (_stream_readable.js:297:12)\n    
    at readableAddChunk (_stream_readable.js:272:9)\n    
    at ReaddirpStream.Readable.push (_stream_readable.js:213:10)\n    
    at ReaddirpStream._read (/Users/danielreid/Projects/depcheck/node_modules/readdirp/index.js:140:22)

slavoroi · 2021-12-21T14:36:18Z

I can confirm, I get the same error messages.
Using node 16.13.0, npm 6 and depcheck 1.4.0, 1.4.1 and 1.4.2.

It's a babel-parser issue.
You didn't lock the babel-parser version in your dependencies and it broke your library.

@babel/parser@7.16.6

return plugins.some(p => {
    if (typeof p === "string") {
      return expectedOptionsIsEmpty && p === expectedName;
    } else {
      const [pluginName, pluginOptions] = p;

      if (pluginName !== expectedName) {
        return false;
      }

capsuleman · 2021-12-28T10:53:12Z

I can confirm, I get the same error messages. Using node 16.13.0, npm 6 and depcheck 1.4.0, 1.4.1 and 1.4.2.

It's a babel-parser issue. You didn't lock the babel-parser version in your dependencies and it broke your library.

@babel/parser@7.16.6
return plugins.some(p => {
    if (typeof p === "string") {
      return expectedOptionsIsEmpty && p === expectedName;
    } else {
      const [pluginName, pluginOptions] = p;

      if (pluginName !== expectedName) {
        return false;
      }

I can confirm, I modified my yarn.loock file to change the @babel/parser version to 7.16.5 and the errors have diseapeared. Thanks!

Chocobozzz · 2021-12-28T14:05:31Z

7.16.5 does not seem to work on my side. Had to install 7.16.4. package.json config for people that use yarn:

  "resolutions": {
    "depcheck/@babel/parser": "7.16.4"
  },

and then run yarn install to update yarn.lock

depcheck/depcheck#688

Installing latest version of babel core in eslint config had a side-effect of deduping and hoisting this version for every package in the monorepo, which in turn broke depcheck package because of depcheck/depcheck#688 As the issue is not resolved yet on the depcheck side, our best way of handling this is to make sure that we are not using this version of babel yet, but as soon as fix is released, we should do a depcheck update in the monorepo

…rser configs (#2815) * fix(eslint-config-compass): Fix babel version at 7.14 Installing latest version of babel core in eslint config had a side-effect of deduping and hoisting this version for every package in the monorepo, which in turn broke depcheck package because of depcheck/depcheck#688 As the issue is not resolved yet on the depcheck side, our best way of handling this is to make sure that we are not using this version of babel yet, but as soon as fix is released, we should do a depcheck update in the monorepo * fix(eslint-config-compass): Separate js and ts parser configs Having babel as default and overriding it with typescript leads to weird parsing issues when running lint for packages in the monorepo * test(compass-aggregations): Skip tests that fail in evergreen

Two fixes are necessary to the depcheck configuration so that it does not report errors around TypeScript files: * Don't report anything around `@types/*` packages, as those are implicitly imported by TypeScript * Pin the version of `@babel/parser` that depcheck uses as the one it's currently using breaks the TypeScript parsing code, causing depcheck to complain about anything imported in TypeScript files. Related GH issue: <depcheck/depcheck#688>

stale · 2022-04-27T19:12:52Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

When support for TypeScript was added, I noticed that `depcheck` was failing to properly detect dependencies in TypeScript files (running `DEBUG=depcheck:* yarn depcheck` revealed that `depcheck` produced a "p is not iterable" error whenever encountering these files). According to [this GitHub issue], this error seems to be caused by some change in `@babel/parser`. The solution suggested there was to pin `@babel/parser` to 7.16.4, so I added a resolution to `package.json` to achieve this. However, since then we've discovered that `yarn-deduplicate` will undo changes to `yarn.lock` that `yarn install` makes, meaning any developer will need to run `yarn-deduplicate` if they want to update dependencies locally or else CI will fail. The aforementioned resolution for `@babel/parser` seems to be the culprit. `@babel/parser` is used by a lot of packages, but the resolution only targeted the version that `depcheck` used. This meant that multiple versions of `@babel/parser` were valid depending on the version resolution logic being used, leading to indeterminate behavior. To fix this problem, this commit updates the resolution such it is more global, i.e., any time `@babel/parser` is referenced, only *one* version will be used. This does lead to a warning when `yarn install` is run, so maybe there is a better way to do this, but the alternative is to add unnecessary exceptions to `.depcheckrc.yml` which seemed undesirable. [1]: depcheck/depcheck#688 (comment)

When support for TypeScript was added, I noticed that `depcheck` was failing to properly detect dependencies in TypeScript files (running `DEBUG=depcheck:* yarn depcheck` revealed that `depcheck` produced a "p is not iterable" error whenever encountering these files). According to [this GitHub issue][1], this error seems to be caused by some change in `@babel/parser`. The solution suggested there was to pin `@babel/parser` to 7.16.4, so I added a resolution to `package.json` to achieve this. However, since then we've discovered that `yarn-deduplicate` will undo changes to `yarn.lock` that `yarn install` makes, meaning any developer will need to run `yarn-deduplicate` if they want to update dependencies locally or else CI will fail. The aforementioned resolution for `@babel/parser` seems to be the culprit. `@babel/parser` is used by a lot of packages, but the resolution only targeted the version that `depcheck` used. This meant that multiple versions of `@babel/parser` were valid depending on the version resolution logic being used, leading to indeterminate behavior. To fix this problem, this commit updates the resolution such it is more global, i.e., any time `@babel/parser` is referenced, only *one* version will be used. This does lead to a warning when `yarn install` is run, so maybe there is a better way to do this, but the alternative is to add unnecessary exceptions to `.depcheckrc.yml` which seemed undesirable. [1]: depcheck/depcheck#688 (comment)

danielreidwoebot added the bug label Dec 14, 2021

hedgepigdaniel mentioned this issue Dec 15, 2021

fix: arguments to @babel/parser #690

Closed

kpala mentioned this issue Dec 29, 2021

Depcheck fails on express, socketio, mongodb #693

Closed

antongolub added a commit to antongolub/tsc-esm-fix that referenced this issue Dec 30, 2021

test: depcheck workaround

f5ef8d9

depcheck/depcheck#688

antongolub added a commit to antongolub/tsc-esm-fix that referenced this issue Dec 30, 2021

test: depcheck workaround

e5d1cad

depcheck/depcheck#688

This was referenced Jan 6, 2022

Fix babel plugin syntax in typescript parser #695

Closed

Fix typescript babel config #692

Closed

gribnoysup mentioned this issue Feb 21, 2022

fix(eslint-config-compass): Fix babel version at 7.14 and separate parser configs mongodb-js/compass#2815

Merged

stale bot added the wontfix label Apr 27, 2022

stale bot closed this as completed Jul 31, 2022

mcmire mentioned this issue Aug 23, 2022

Add resolution for depcheck/@babel/parser correctly MetaMask/metamask-extension#15665

Closed

6 tasks

Gudahtt mentioned this issue Aug 24, 2022

Update depcheck to latest version MetaMask/metamask-extension#15690

Merged

6 tasks

jportner mentioned this issue Apr 12, 2023

Upgrade Babel parser to support Typescript 5.0 #788

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Running against .ts files fails with error: 'TypeError: p is not iterable' #688

Running against .ts files fails with error: 'TypeError: p is not iterable' #688

danielreidwoebot commented Dec 14, 2021

rumpl commented Dec 14, 2021

danielreidwoebot commented Dec 14, 2021

hedgepigdaniel commented Dec 15, 2021

danielreidwoebot commented Dec 15, 2021

danielreidwoebot commented Dec 15, 2021 •

edited

slavoroi commented Dec 21, 2021 •

edited

capsuleman commented Dec 28, 2021

Chocobozzz commented Dec 28, 2021

stale bot commented Apr 27, 2022

Running against .ts files fails with error: 'TypeError: p is not iterable' #688

Running against .ts files fails with error: 'TypeError: p is not iterable' #688

Comments

danielreidwoebot commented Dec 14, 2021

Bug Description

Versions

rumpl commented Dec 14, 2021

danielreidwoebot commented Dec 14, 2021

hedgepigdaniel commented Dec 15, 2021

danielreidwoebot commented Dec 15, 2021

danielreidwoebot commented Dec 15, 2021 • edited

slavoroi commented Dec 21, 2021 • edited

capsuleman commented Dec 28, 2021

Chocobozzz commented Dec 28, 2021

stale bot commented Apr 27, 2022

danielreidwoebot commented Dec 15, 2021 •

edited

slavoroi commented Dec 21, 2021 •

edited