got: tsc can't resolve types for got 13

ESM is still dead in the water for 99% of real-world projects. Which is an improvement from 100% of like a year back. But it doesn’t mean you have to skip updating got. This is my tsconfig:

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "baseUrl": ".",
    "module": "CommonJS",
    "moduleResolution": "node",
    "isolatedModules": true,
    "esModuleInterop": true,
    "strict": true,
    "downlevelIteration": true,
    "paths": {
      "~/*": [
        "./src/*"
      ],
      "got": ["./node_modules/got/dist/source"]
    }
  }
}

I am wondering what could go wrong with this solution ?

{
	"name": "got",
	"version": "13.0.0",
	"description": "Human-friendly and powerful HTTP request library for Node.js",
	"license": "MIT",
	"repository": "sindresorhus/got",
	"funding": "https://github.com/sindresorhus/got?sponsor=1",
	"type": "module",
	"types": "./dist/source/index.d.ts",
	"exports": {
		"types": "./dist/source/index.d.ts",
		"default": "./dist/source/index.js"
	},

Until got version 12.6.0 types attribute was present in package.json.

In version 13.0.0 it was removed.

If I manually restore this line it works with nextjs 13.

Is there any potential issue restoring the types attribute ?

Heads up that node16 module resolution does not work in Next.js projects.

My builds also started failing on v13 with error TS2307: Cannot find module 'got' or its corresponding type declarations.

why we need support this esm 😦 most framework dont support esm

We should continue to push the wave of ESM, but removing the types field doesn’t seem to be the way for me. There are just so many constraints in the real world that disallow us to use node16 in the foreseeable future

Got has been an ESM package since v12. You must have "module": "node16", "moduleResolution": "node16" in your tsconfig.

The package’s author does not care much about making the changes needed to make it work again. 🙂 I am. We ended up getting blocked from upgrading. Now, the team suggests dropping the package in favor of other competitors as we have 500+ consumers (businesses), and nobody can upgrade, as the changes mentioned here are not feasible. I am so sorry to leave the package, as we had some great experiences with it till V13 was released. You might be surprised, but some companies run SOC 2 audits as well, and we are forced to keep the package up to date, so without having the option to make this backward compatible, we are going to switch to fat alternatives, unfortunately.

When the version you are trying to push does not gat the traction, it probably would be a good idea to think twice before killing userbase.

Here’s a workaround for Next.js@13:

declare module 'got' {
    import * as got from 'got/dist/source';
    export = got;
}

I don’t get the author’s intention. Hundreds of people have spent time searching for and fixing a problem that may not have existed.

this change also breaks webstorm autocomplete

Typescript 5.2 now explicity fails to build when you mix module and moduleResolutions in ways you’re not meant to.

See https://github.com/microsoft/TypeScript/pull/54567

error TS5110: Option 'module' must be set to 'Node16' when option 'moduleResolution' is set to 'Node16'.

(or some variation of that).

This means anyone upgrading to 5.2 and using got 13.0.0 will suddenly hit this error.

Using the above from @datner, I managed to get a repo working but ran into another error.

The other error - ERR_UNSUPPORTED_DIR_IMPORT - had a simple fix.

I used this change to tsconfig.json:

"paths": {
    "got": ["./node_modules/got/dist/source/index.js"]
},

I figured I’d mention it here now that 5.2 is out and this may become a larger issue before the end of the year.

Seeing this as well, even with a vanilla js workspace w/ “type”: “module” set (not using typescript, it’s just that type completion doesn’t work at all for the same reasons outlined above). Suspecting it has to do with the lack of “types” specification in package.json 😦

Same problem

people want to push ESM hard but not everyone can afford the switch. libraries should provide commonjs modules as an alternative but the maintainers just don’t care 🥲

Unfortunately certain customers that are using my SDK (that relies on Got) are also experiencing the same issue and it becomes a bit of a problem as it’s not feasible for them to try all the solutions listed in this thread. I decided to give the Fetch API a go instead and it seems to do the trick

For those who wants to disable the warning, please refer to https://github.com/vercel/next.js/discussions/49432 and https://github.com/jaredwray/keyv/issues/45:

- warn Compiled with warnings

./node_modules/keyv/src/index.js
Critical dependency: the request of a dependency is an expression

Import trace for requested module:
./node_modules/keyv/src/index.js
./node_modules/cacheable-request/dist/index.js
./node_modules/got/dist/source/core/index.js
./node_modules/got/dist/source/index.js
./src/app/api/bug/route.ts

You can override the webpack configuration with:

/** @type {import('next').NextConfig} */
const nextConfig = {
  // ...
  webpack: (config) => {
    // Ignore ALL webpack warnings produced by ./node_modules/keyv/src/index.js file
    config.ignoreWarnings = [
      { module: /node_modules\/keyv\/src\/index\.js/ },
    ];

    return config;
  },
};

module.exports = nextConfig;

⚠️ Note that it will ignore ALL warnings produced by this file, not only the request of a dependency is an expression but you can improve the snippet to filter only this message, please refer to ignoreWarnings documentation

Tells webpack to ignore specific warnings. This can be done with a RegExp, a custom function to select warnings based on the raw warning instance which is getting WebpackError and Compilation as arguments and returns a boolean, an object with the following properties:

@trim21 share the patch then

read the issue description again

converteting next to use ESM.

as far as I know, nextjs do not support and are not planning or intending to support esm, so I am not surprised that got and most probably others won’t work without more extensive hacking 😄

in general, it’s really quite confusing that everyone supports the import syntax or browser es modules. But practically no one supports node16 esm

For context, my attempt at adding node16 support to next.js

https://github.com/vercel/next.js/pull/50357

I don’t think it is possible to make it work using the current setup.

You only need node16 if you run code code directly generated by tsc, or you are using ts-node.

for example, tsc --outDir dist && node ./dist/index.js or ts-node-esm ./src/index.ts

Another sulution is to upgrade typescript to 5.0 and set moduleResolution to bundler.

This works if you are using any tools to transpile or bundle your server project source files (including nodejs esm loader @esbuild-kit/esm-loader, webpack, rollup, esbuild …etc).

for examaple, if you are using @esbuild-kit/esm-loader to run your TypeScript esm project directly, or you build your TS project with rollup and run the generated javascript files, you should set moduleResolution to bundler.

This is beacuse nodejs esm loader can be more powerful then nodejs cjs hook. If you are using bundler or esm-loader (@esbuild-kit/esm-loader or tsx), your are not actually using node16 esm moduleResolution, you are using the module resolution algorithm provided by the esm-loader or bundler.

But sadly, ts-node-esm does nothing but transpile, so you will need node16 if you are using ts-node.