octokit.js: isPlainObject.isPlainObject is not a function - error after compiling with ncc

Checklist

Environment

Versions

├─┬ @octokit/rest@18.0.9
│ ├─┬ @octokit/core@3.2.1
│ │ ├─┬ @octokit/auth-token@2.4.3
│ │ ├─┬ @octokit/graphql@4.5.7
│ │ ├─┬ @octokit/request@5.4.10
│ │ │ ├─┬ @octokit/endpoint@6.0.9
│ │ │ ├─┬ @octokit/request-error@2.0.3
│ │ ├─┬ @octokit/types@5.5.0
│ ├─┬ @octokit/plugin-paginate-rest@2.6.0
│ ├── @octokit/plugin-request-log@1.0.2
│ └─┬ @octokit/plugin-rest-endpoint-methods@4.2.1

What happened?

On upgrading to @octokit/rest@18.0.9 from 18.0.5, our compiled (using ncc) project doesn’t run, with the following error:

/home/runner/work/use-herald-action/use-herald-action/dist/index.js:8906
    if (isPlainObject.isPlainObject(options[key])) {
                      ^

TypeError: isPlainObject.isPlainObject is not a function
    at /home/runner/work/use-herald-action/use-herald-action/dist/index.js:8906:23
    at Array.forEach (<anonymous>)

Might be worth noting that we were also seeing this error a few days ago when trying to upgrade to 18.0.7 from 18.0.5.

I believe this might be an issue when @octokit/rest interacts with webpack, since our project runs and passes tests locally, without compiling. An issue similar to this one was reported in #1354 and resolved in the 16.25.4 release.

Minimal test case to reproduce the problem

EDIT: Minimal repro created by @gagoar: https://github.com/octokit/rest.js/issues/1929#issuecomment-722011156

While I don’t have a minimal test case, I hope the following is helpful in diagnosing the issue:

Renovate PR that produced the error: https://github.com/gagoar/use-herald-action/pull/235 In particular, this GitHub action dry-runs the project after compiling with ncc: https://github.com/gagoar/use-herald-action/pull/235/checks?check_run_id=1343946483

npm ls is-plain-object

use-herald-action@2.3.0 /Users/siliu/GitHub/gagoar/use-herald-action
├─┬ @octokit/rest@18.0.9
│ └─┬ @octokit/core@3.2.1
│   └─┬ @octokit/request@5.4.10
│     ├─┬ @octokit/endpoint@6.0.9
│     │ └── is-plain-object@5.0.0        <------ 5.0.0
│     └── is-plain-object@5.0.0          <------ 5.0.0
└─┬ jest@26.6.2
  └─┬ @jest/core@26.6.2
    └─┬ jest-haste-map@26.6.2
      └─┬ sane@4.1.0
        └─┬ micromatch@3.1.10
          ├─┬ extend-shallow@3.0.2
          │ └─┬ is-extendable@1.0.1
          │   └── is-plain-object@2.0.4   <------ 2.04
          └─┬ snapdragon@0.8.2
            └─┬ base@0.11.2
              ├─┬ cache-base@1.0.1
              │ └─┬ set-value@2.0.1
              │   └── is-plain-object@2.0.4  deduped <------ 2.04
              └─┬ mixin-deep@1.3.2
                └─┬ is-extendable@1.0.1
                  └── is-plain-object@2.0.4  deduped <------ 2.04

cc @gagoar

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 24 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Just checked out why esbuild does this. It’s caused by this line in tsconfig.json:

"*": ["node_modules/*"]

This tells esbuild to check that folder first and that any match there takes priority over the normal module resolution process. Removing this line means esbuild falls back to node’s module resolution algorithm which resolves is-plain-object correctly.

I would just post an issue in both bundlers. Maybe resolvers are not properly setup in both cases. There is nothing to do with is-plain-object except reverting all goodies and going back to 2 like exports. Though tomorrow another package may break the same way.

Hey @TrySound, thanks for working with @gagoar to look into the issue. It does look like a bundler problem as you suggested.

One theory is that webpack might be configured to resolve root modules only similar to here: https://stackoverflow.com/questions/48825061/webpack-sub-modules-not-resolved-correctly

I installed is-plain-object@5.0.0 as a toplevel dependency in the reproduction repository here: https://github.com/gagoar/is-plain-object-error-repro/pull/4 which has seemed to resolve the issue. So, there’s no problem with is-plain-object and the named export can (and should) stay.

I also tried removing jest as a dependency since it depends on is-plain-object@2.0.4. This also fixed our issues: https://github.com/gagoar/is-plain-object-error-repro/pull/5. Should be safe to conclude at this point that ncc and esbuild are both incorrectly resolving is-plain-object@2.0.4 when octokit asks for is-plain-object@5.0.0.

I’ll see to opening issues in ncc and esbuild, in that order.

Looks like the issue is bundling node_modules/is-plain-object (default export) instead of node_modules/@octokit/request/node_modules/is-plain-object (named export). Something with ncc resolver. I think it’s worth to open the issue in their repo.

Repo to reproduce issue

https://github.com/gagoar/is-plain-object-error-repro

Checkrun Failing

https://github.com/gagoar/is-plain-object-error-repro/runs/1355424729

I’ve also created a workflow so if you want to test against this repo you can

Github Documentation

Currently, the documentation is suggesting ppl use ncc to build their actions, which will lead to this issue, I can PR a change in the documentation to suggest esbuild given that I’ve already changed another node tools I own to esbuild to solve the problem. like github-installaction-token. But let us know how can we help.