[gatsby-core-utils] update from 1.0.28 to latest causes 3 typescript errors with default export with configstore and module dependencies, and gatsby-link

[JustFly1984]

[gatsby-core-utils] update from 1.0.28 to 1.0.30 brings new dependency configstore "^5.0.0", which causes errors in typescript

Describe the issue that you're seeing.

Steps to reproduce

Clear steps describing how to reproduce the issue. Please please please link to a demo project if possible, this makes your issue much easier to diagnose (seriously).

How to Make a Minimal Reproduction: https://www.gatsbyjs.org/contributing/how-to-make-a-reproducible-test-case/

Expected result

No errors in typescript

Actual result

Got new TS error

error TS1259: Module '"/Users/justfly/projects/poolotto-gatsby/node_modules/@types/configstore/index"' can only be default-imported using the 'esModuleInterop' flag

1 import ConfigStore from "configstore"
         ~~~~~~~~~~~

  node_modules/@types/configstore/index.d.ts:6:1
    6 export = Configstore;
      ~~~~~~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.


Found 1 error.

error Command failed with exit code 1.

Environment

System:
OS: macOS 10.15.2
CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 13.10.1 - ~/.nvm/versions/node/v13.10.1/bin/node
Yarn: 1.22.1 - /usr/local/bin/yarn
npm: 6.13.7 - ~/.nvm/versions/node/v13.10.1/bin/npm
Languages:
Python: 2.7.16 - /usr/bin/python
Browsers:
Chrome: 80.0.3987.132
Firefox: 72.0.2
Safari: 13.0.4
npmPackages:
gatsby: 2.19.32 => 2.19.32
gatsby-plugin-manifest: 2.2.44 => 2.2.44
gatsby-plugin-no-sourcemaps: 2.1.2 => 2.1.2
gatsby-plugin-offline: 3.0.37 => 3.0.37
gatsby-plugin-purgecss: 4.0.1 => 4.0.1
gatsby-plugin-react-helmet: 3.1.23 => 3.1.23
gatsby-plugin-robots-txt: 1.5.0 => 1.5.0
gatsby-plugin-root-import: 2.0.5 => 2.0.5
gatsby-plugin-sitemap: 2.2.28 => 2.2.28
gatsby-plugin-typescript: 2.2.2 => 2.2.2
gatsby-plugin-webpack-bundle-analyzer: 1.0.5 => 1.0.5
npmGlobalPackages:
gatsby: 2.19.32

[JustFly1984]

actually issue is part of updating babel-preset-gatsby

[JustFly1984]

and also this:

[blainekasten]

I think we fixed this. It was because we forgot to list it as an explicit dependency. Can you update to latest and verify?

[JustFly1984]

@blainekasten

I've updated, and still have same TS issue with configstore

yarn lock changes still brings configstore into dependencies:

gatsby-telemetry@^1.1.52 has it
gatsby-core-utils@^1.0.31 has it

the only way to fix TS issue for me is adding resolutions package.json

{
"resolutions": {
    "react-helmet/react-side-effect": "2.1.0",
    "regenerator-runtime": "0.13.4",
    "gatsby-cli": "2.10.0",
    "gatsby-core-utils": "1.0.28",
    "gatsby-page-utils": "0.0.39",
    "gatsby-plugin-page-creator": "2.1.40"
  }
}

and fixing gatsby and babel-preset-gatsby dependencies to next versions:

{
  "dependencies": {
    "gatsby": "2.19.28",
    "babel-preset-gatsby": "0.2.29",
  }
}

sidenote: gatsby-telemetry does not responsible for TS errors, I'm seeing configstore in dependencies, but typescript check does not have conflicts with export/import.

[JustFly1984]

Updating to current version gatsby 2.19.45 and babel-preset-gatsby 0.2.36 provides more typescript errors than before:

node_modules/gatsby-core-utils/dist/create-require-from-path.d.ts:2:8 - error TS1259: Module '"module"' can only be default-imported using the 'esModuleInterop' flag

2 import Module from "module";
         ~~~~~~

  node_modules/@types/node/module.d.ts:57:5
    57     export = Module;
           ~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.

node_modules/gatsby-core-utils/dist/get-config-store.d.ts:1:8 - error TS1259: Module '"/Users/justfly/projects/bitgoals-gatsby/node_modules/@types/configstore/index"' can only be default-imported using the 'esModuleInterop' flag

1 import Configstore from "configstore";
         ~~~~~~~~~~~

  node_modules/@types/configstore/index.d.ts:6:1
    6 export = Configstore;
      ~~~~~~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.


Found 2 errors.

if I'm turning esModuleInterop: true - I'm getting issues with importing json files which renders resolveJsonModule: true useless.

[blainekasten]

@JustFly1984 what version of TS are you using? This feels peculiar that your local is failing because of some typings within the @types dependencies.

[JustFly1984]

@blainekasten We are using latest "typescript": "3.8.3", node 13.11.0

our tsconfig.json

{
  "compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "src/*": ["src/*"]
    },
    "types": [
      "classnames",
      "cypress",
      "intl",
      "node",
      "node-fetch",
      "reach__router",
      "react-dom",
      "react-helmet",
      "react-redux",
      "react-toastify",
      "redux-actions",
      "redux-debounced",
      "showdown",
      "uniqid",
      "webpack",
      "webpack-env"
    ],
    "module": "commonjs",
    "target": "esnext",
    "jsx": "react",
    "lib": ["dom", "es2017"],
    "strict": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": false,
    "resolveJsonModule": true,
    "noUnusedLocals": true,
    "experimentalDecorators": true
  },
  "exclude": ["node_modules", "public", ".cache"]
}

how else can I help to solve this issue?

I have same kind of import issue with other package - react-use - crosslink issue: streamich/react-use#892

[JustFly1984]

@blainekasten still getting same typescript errors in gatsby@2.20.6

please help

[awwit]

@blainekasten this problem is still not resolved.

You just need to change the value esModuleInterop to false in your tsconfig.json.

You will write code on a normal TS without compatibility mode (esModuleInterop). And such problems will no longer appear :)

The fact is that it is possible to write code without problems with the esModuleInterop flag and solve import problems yourself (TS provide operators for import different modules), without relying on automatic compatibility.

The main thing is that without the esModuleInterop flag your code will be compatible with projects that use this flag for assembly (and with those projects that don’t use it).

We in our projects set the value of the esModuleInterop flag to false — we get such errors.
And with this flag the project is not built, since we import each module in the way it was written.

---

Here's how to fix gatsby-core-utils module errors:

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-core-utils/src/create-require-from-path.ts#L1
change to:

import * as Module from "module"

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-core-utils/src/get-config-store.ts#L1
change to:

import * as Configstore from "configstore"

[blainekasten]

@awwit @JustFly1984 I tried reproducing this and couldn't.. Could you share how you are using gatsby-core-utils. Are you using these utils in react code? or in gatsby-* configuration files?

[JustFly1984]

@blainekasten @awwit So hear me out - I dug deep into gatsby code, and it using node v10.x as default. I have successfully fixed issue with Configstore by changing esModuleInterop to false and fixing imports to * as everywhere, but issue with Module is much deeper. It is not possible to import it correctly if node does not have es6 imports, and node has it only since 13.2.0 version, hence @types/node should be used starting @13.x, but there is yarn workspaces and node version bump means major version bump. I'm in progress of major refactoring to typescript for gatsby-cli and gatsby-core-utils, will try to make PR at the end of the week. It is not possible to change node version for one package, it is required to change versions everywhere. I'm not sure how it is possible to merge changes since I've forked gatsby repo at saturday.

@blainekasten Is there a way to remove dependency on Module in gatsby-core-utils ?

[awwit]

@blainekasten you are right, the problem is not in the build, it is successful.

The problem occurs when we run npx tsc --noEmit. The typescript@3.8.3 compiler finds these errors when analyzing the entire project.

Our project is configured so that when trying to commit, the code is checked for validity using typescript.

Now I saw where the problem is: you include *.d.ts files in the library package. In which the compiler finds errors. Probably *.d.ts files were mistakenly in the assembly.

[JustFly1984]

@blainekasten Please customize only required types in tsconfig.json in each repo which works with typescript. Also you need to update @types/node for gatsby-core-utils and node to 13.3.0 at least, to support Module.

[JustFly1984]

@blainekasten Now after attempt to update gatsby to 2.20.10 I got one typescript error more.
One more error comes from gatsby-link conflict with @types/react

node_modules/gatsby-core-utils/dist/create-require-from-path.d.ts:2:8 - error TS1259: Module '"module"' can only be default-imported using the 'esModuleInterop' flag

2 import Module from "module";
         ~~~~~~

  node_modules/@types/node/module.d.ts:57:5
    57     export = Module;
           ~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.

node_modules/gatsby-core-utils/dist/get-config-store.d.ts:1:8 - error TS1259: Module '"/Users/justfly/projects/wallet-bitgoals-gatsby/node_modules/@types/configstore/index"' can only be default-imported using the 'esModuleInterop' flag

1 import Configstore from "configstore";
         ~~~~~~~~~~~

  node_modules/@types/configstore/index.d.ts:6:1
    6 export = Configstore;
      ~~~~~~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.

node_modules/gatsby-link/index.d.ts:4:18 - error TS2430: Interface 'GatsbyLinkProps<TState>' incorrectly extends interface 'LinkProps<TState>'.
  Types of property 'innerRef' are incompatible.
    Type 'Function | undefined' is not assignable to type '((instance: HTMLAnchorElement | null) => void) | RefObject<HTMLAnchorElement> | null | undefined'.
      Type 'Function' is not assignable to type '((instance: HTMLAnchorElement | null) => void) | RefObject<HTMLAnchorElement> | null | undefined'.
        Property 'current' is missing in type 'Function' but required in type 'RefObject<HTMLAnchorElement>'.

4 export interface GatsbyLinkProps<TState> extends LinkProps<TState> {
                   ~~~~~~~~~~~~~~~

  node_modules/@types/react/index.d.ts:88:18
    88         readonly current: T | null;
                        ~~~~~~~
    'current' is declared here.


Found 3 errors.

[JustFly1984]

crosslinking: #22754

[JustFly1984]

@blainekasten @awwit I'm currently found the only way to workaround current 3 TS bugs, is add flag --skipLibCheck to tsc invocation before lint-staged.

this is my set of npm scripts for those who has same issues as me:

    "tc": "npx tsc -p ./tsconfig.json --noEmit",
    "tc:trace-resolution": "npx tsc -p ./tsconfig.json --noEmit --traceResolution",
    "tc:skip-lib-check": "npx tsc -p ./tsconfig.json --noEmit --skipLibCheck",

without --skipLibCheck there is 3 typescript errors. I'm still afraid that there could be some other serious dependency issue, so we are going to update dependencies manually, instead of merging commits automatically with dependabot.

[JustFly1984]

#21995

[bsgreenb]

Thanks @JustFly1984 .. I'm going to use your --skipLibCheck until a fix is posted.

[JustFly1984]

currently 3 errors has been dissapeared in 2.22.19 version, but one more appeared:

node_modules/gatsby/index.d.ts:14:27 - error TS2307: Cannot find module './src/bootstrap/load-plugins/types' or its corresponding type declarations.

14 import { PluginRef } from "./src/bootstrap/load-plugins/types"
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 1 error.

error Command failed with exit code 1.

#24758

[JustFly1984]

Closing an issue, due to correct fix