Here's a different approach

If you're working with a module that isn't your own, consider installing type definitions using @types:

npm install -D @types/module-name

When you bring in a third-party module called 'foo' that lacks any typings, whether in the library itself or in the @types/foo package (created from the DefinitelyTyped repository), you can resolve this issue by defining the module in a file with a .d.ts extension. TypeScript will search for .d.ts files in the same locations where it searches for regular .ts files, as specified in the "files", "include", and "exclude" sections of the tsconfig.json file.

// foo.d.ts
declare module 'foo';

When you import foo, it will simply be typed as any.

---

Alternatively, if you wish to create your own typings, you can do so:

// foo.d.ts
declare module 'foo' {
    export function getRandomNumber(): number
} 

Now, this will compile without any issues:

import { getRandomNumber } from 'foo';
const x = getRandomNumber(); // x is inferred as number

You do not need to provide comprehensive typings for the module. Just include enough for the parts you are using and want accurate typings for. This is especially simple if you are only utilizing a small portion of the API.

---

Alternatively, if you are unconcerned about the typings of external libraries and prefer all libraries without typings to be imported as any, you can include the following in a file with a .d.ts extension:

declare module '*';

The advantage (and drawback) of this approach is that you can import any library and TypeScript will compile without errors.

In situations where you require an immediate solution, just insert this snippet before your import line:

// @ts-ignore

If you're facing the same issue, consider changing the file extension from .js to .ts

Additional tip: To solve this, you can include "allowJs": false in your tsconfig file.

Incorporating TypeScript into your codebase involves implementing specific rules and adding type annotations to enhance clarity and accuracy, particularly in contrast to the flexibility of JavaScript. TypeScript prompts developers to define the data used in their code, allowing the compiler to detect and report any errors. Through this process, mismatched types, scope violations, and incorrect returns can be identified and addressed promptly.

When utilizing external libraries and modules with TypeScript, it is necessary for these entities to have accompanying type declaration files, denoted by the extension d.ts. Fortunately, many declaration types for npm modules are readily available and can be included using the command npm install @types/module_name (with the specific module name). However, for modules lacking type definitions, developers can resolve errors by creating a custom type file within a designated typings folder in their project root.

To achieve this, developers should create a new folder named after the module within the typings directory, in which a corresponding module_name.d.ts file is generated with the declaration declare module 'module_name'. Subsequently, the project's tsconfig.json file should be updated with the addition of

"typeRoots": [ "../../typings", "../../node_modules/@types"]

under compilerOptions and

"exclude": ["../../node_modules", "../../typings"]

to specify where TypeScript can locate type definitions for libraries and modules.

By following this methodology, developers can resolve errors, adhere to the latest ES6 and TypeScript guidelines, and maintain a more robust and error-free codebase.

This is the method that has proven effective for me:

1. Create your own declaration in a declaration file like custom.d.ts (perhaps located in the project's root directory)

declare module 'Injector';

2. Add your custom.d.ts file to tsconfig.json

  {
    "compilerOptions": {
        "strictNullChecks": true,
        "moduleResolution": "node",
        "jsx": "react",
        "noUnusedParameters": true,
        "noUnusedLocals": true,
        "allowSyntheticDefaultImports":true,
        "target": "es5",
        "module": "ES2015",
        "declaration": true,
        "outDir": "./lib",
        "noImplicitAny": true,
        "importHelpers": true
      },
      "include": [
        "src/**/*",
        "custom.d.ts",   // path to declaration file
      ],
      "compileOnSave": false
    }

It's sometimes beyond our control whether the developer includes a declaration file. My workaround is to create a file called index.d.ts where I add missing declaration files for different packages:

Index.d.ts:

declare module 'v-tooltip';
declare module 'parse5';
declare module 'emoji-mart-vue-fast';

Then, refer to it in your tsconfig.js:

"include": [
    "src/**/*.ts",
    "src/**/*.tsx",
    "src/**/*.vue",
    "tests/**/*.ts",
    "tests/**/*.tsx",
    "index.d.ts" // this
  ]

To add type declarations for a module in your project, simply create a file named typings.d.ts at the root level. Within this file, use the syntax

declare module <module_name>

, where module_name is the name of the module you wish to import. Next, update the tsconfig.json file to include the typings.d.ts file in the include array.

// typings.d.ts
declare module 'abc-module';

// tsconfig.json
{
  ...
"include": [
    "src", "typings.d.ts"
  ]
}

// Voila, issue resolved!!!

By following this method, your module will now have a defined type instead of just "any". For further details, check out: https://medium.com/@steveruiz/using-a-javascript-library-without-type-declarations-in-a-typescript-project-3643490015f3

This solution did the trick for me.

// typing.d.ts 
declare module 'my-library';

// tsconfig.json 
{
  ...
  "include": [
    ...
    "src", "typing.d.ts"
  ]
}

// Importing
import * as MyLibrary from 'my-library'
...
const myLibrary = MyLibrary()
...

This is how I managed to get it working.

In my situation, I utilized a library without defined types: react-mobile-datepicker

a. Establish a directory within /src. In my instance, I chose: /src/typings/.

b. Create a .d.ts file. In this case:

/src/typings/react-mobile-datepicker.d.ts

c. I implemented this code to enhance its attributes and ensure type safety:

declare module 'react-mobile-datepicker' {
  class DatePicker extends React.Component<DatePickerProps, any> {}

  interface DatePickerProps {
    isPopup?: boolean;
    theme?: string;
    dateConfig?: DatePickerConfig;
  }

  export interface DatePickerConfig {
    prop1: number;
    prop2: string;
  }
  export default DatePicker;
}

d. Import your types as you normally would when utilizing the 3rd party library.

import DatePicker, { DatePickerConfig, DatePickerConfigDate } from 'react-mobile-datepicker';

e. Modify tsconfig.json and include this snippet:

{
  "compilerOptions": {
    //...other properties
    "typeRoots": [
      "src/typings",
      "node_modules/@types"
    ]
  }}

Here are the links to the articles I referenced:

Resolution: Simply make changes to your TypeScript Configuration document tsconfig.json by including a fresh key-value combination:

"compilerOptions": {
"noImplicitAny": false
}

Make sure to review the content of your "tsconfig.json" file to adjust the compilation options for "include" and "exclude". If these options are missing, simply add them to your main folder.

// tsconfig.json
{
  "compilerOptions": {
  ...
  "include": [
    "src", 
  ],
  "exclude": [
    "node_modules", 
  ]
}

In my case, I was able to resolve an issue by removing the file extension statement "*.spec.ts" from the "exclude" section. This change prevented any problems that arose when importing modules in those specific files.

Here is a straightforward solution:

// file-example.d.ts
declare module 'bar';

If you wish to define an interface for an object (Highly recommended for larger projects), you can follow this approach:

// file-example.d.ts
declare module 'bar'{
    // an example
    export function getUsername(): string
}

How can you implement this? It's very simple!

const y = require('bar') // or import y from 'bar'
y.getUsername() // Your IDE can provide suggestions for this

Installing a types package for your dependency is typically the recommended approach. However, another option would be to include allowJs -> true in your tsconfig.json file

In the event that you have successfully installed the module but continue to encounter an error message, a simple yet effective solution is to disregard the error by including the following line of code above the problematic line:

// @ts-ignore: Unreachable code error

Both @ktretyak and @Retsam provided correct answers, but I wanted to share a real-time example and what worked for me:

Issue:

Error TS7016 (TS) Could not find a declaration file for module 'react-region-select'.

'C:/Repo/node_modules/react-region-select/lib/RegionSelect.js' implicitly has an 'any' type.

Try

npm i --save-dev @types/react-region-select

if it exists or add a new declaration (.d.ts) file containing `declare module

When I tried to run

npm i --save-dev @types/react-region-select

, I encountered the following error:

npm ERR! code E404

npm ERR! 404 Not Found - GET https://registry.npmjs.org/@types%2freact-region-select - Not found

npm ERR! 404 '@types/react-region-select@latest' is not in the npm registry.

npm ERR! 404 You should bug the author to publish it (or use the name yourself!)

npm ERR! 404 Note that you can also install from a npm tarball, folder, http url, or git url.

Since create-react-app generates a file named

react-app-env.d.ts</code, I tried to declare the module by adding <code>declare module 'react-region-select';

in that file, but the error persisted.

My next step was to create a new folder named typings within src, along with a file named react-region-select.d.ts. In this file, I declared the module as follows:

declare module 'react-region-select';

After making this adjustment, the error disappeared and I was able to import it as per the documentation:

import RegionSelect from "react-region-select"; 

https://github.com/casavi/react-region-select

Despite trying three different methods to resolve the issue, none of them proved successful in my case. By specifying "type" as "module" in the package.json file, ES Module syntax can be used instead of CommonJS. Adhering to the ES Module syntax based on the package.json settings resolved the issue for me.

import ws from 'ws'

export const create = (/** @type {string} */ accessToken) => {
    const WebSocket = ws;
    return new WebSocket(endpoint, accessToken, sslOptions);
}

By following this approach, the WebSocket class in the 'ws' module can be utilized. Although this example pertains to a node module, it is applicable to any type of node module with its functions.

The following methods did NOT work for me:

1. npm install -D @types/module-name

2. const foo = require('module-name');

// index.d.ts
declare module 'foo';

4. Configurations from tsconfig.json

"noImplicitAny": true,
"allowJs": true

Despite trying numerous solutions, my issue turned out to be unrelated to the common fixes mentioned: I found that the problem was resolved after I removed any import statements from my *.d.ts file:

import { SomeModuleType } from '3rd-party-module';

Simply removing this line made the error disappear...

Further Explanation: When a module is declared in a *.d.ts file, it is automatically recognized by the Typescript compiler as an ambient module (requiring no explicit import). However, once an import ... from ... statement is added, the file is transformed into a standard (ES6) module, losing its automatic recognition. To maintain the module as an ambient module, a different import style can be used, like so:

type MyType: import('3rd-party-module').SomeModuleType;

After facing numerous challenges with packages in various projects, I decided to tackle the issue by creating my own solution called Declarator. This npm package is designed to automatically generate type declarations.

The process essentially involves executing tsc --emitDeclarationOnly in the background.

To get started, you can easily install Declarator from npm:

npm install --save-dev declarator
yarn add -D declarator

Next, simply create a straightforward declarator.json file:

{
  "$schema": "https://raw.githubusercontent.com/ArthurFiorette/declarator/master/schema.json",
  "packages": ["package1","package2"]
}

Don't forget to set up a script to run the tool:

Consider utilizing the postinstall script to trigger it during every package installation, which could prove to be beneficial

{
  "scripts": {
    "postinstall": "declarator"
  }
}

While it may not yield robust types and you may encounter instances of any types, it's still a significant improvement compared to not using it at all.

For additional information, visit: https://github.com/ArthurFiorette/declarator#readme

I encountered a similar issue, and it had me puzzled for quite some time. Despite having the necessary module and types installed, as well as reloading my IDE multiple times, the problem persisted.

The solution for me was to end terminal processes, delete the node_modules folder, clear the node package manager cache, perform a fresh install, and then reopen the editor. This resolved the issue for me.

Encountering a similar problem, I encountered an issue while using a node module in a react application built with typescript. The module was installed successfully using npm i --save my-module. This particular module is written in javascript and exports a Client class.

However, when I tried to use it in my project with the following code:

import * as MyModule from 'my-module';
let client: MyModule.Client = new MyModule.Client();

I faced a compilation error:

Could not find a declaration file for module 'my-module'. 
'[...]/node_modules/my-module/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/my-module` if it exists or add a new declaration (.d.ts) file containing `declare module 'my-module';`

Despite the absence of @types/my-module, I created a my-module.d.ts file in the same directory where I imported my-module as suggested. This resulted in another error:

Namespace '"my-module"' has no exported member 'Client'.

Interestingly, the client was exported and functioned correctly when used in a js application. Moreover, the compiler was searching for the client in the correct file (

/node_modules/my-module/lib/index.js

as specified in my-module/package.json "main" element).

To resolve this issue, I chose to disregard the implicit any error by setting the following line in my tsconfig.json file to false:

    "noImplicitAny": false,

If encountering this issue while using Webstorm, and you have recently installed a new package, it may be necessary to restart the typescript service for it to take effect.

• Access the help menu
• Lookup an action
• Search for Restart Typescript Service

https://i.sstatic.net/NtIPY.png

https://i.sstatic.net/AbaFI.png

The issue at hand arises due to the configuration of TypeScript with an outdated moduleResolution setting. By adjusting the tsconfig.json to include moduleResolution: "nodenext", the required types from the package.json definitions will be located correctly.

However, implementing this change may lead to complications within your current repository.

As a workaround, consider the following solution:

Create a re-exporting .ts file for each entry that is not located precisely as expected by TypeScript.

In your specific scenario, adding /index.ts to your package (with the .ts extension, without converting to

.js</code) is advised. The content of this file should be straightforward:</p>
<pre><code>// Placeholder to satisfy TypeScript. Do not add an extension to the import!
export * from "./dist"

The path being re-exported should not include extensions, enabling TypeScript to resolve it and locate the associated index.d.ts types file. If the types file is named differently than expected by TypeScript when importing from JavaScript files, a renaming may be necessary.

In the scenario where a package is being developed with exports, a similar approach should be taken. For instance, if an export such as /vite corresponds to /dist/vite.mjs, you should include the file /vite/index.ts with

export * from "../dist/vite"

. This file will only be recognized by TypeScript.

Expanding upon Retsam's suggestion, incorporating wildcards (*) in your declarations.d.ts file can also be beneficial. For instance, when attempting to bring in a file such as a .css or .webp file, adding a * at the start of the file type declaration can be advantageous. This implementation could appear as shown below ⤵︎

declare module '*.webp';

Subsequently, the ability to import numerous .webp files freely, minus any linting complications, is now attainable.

In my experience, I had success by including an aliases entry that enabled typescript to locate the declaration file:

// tsconfig.json
{
    "compilerOptions": {
        ...
        aliases: {
            "*": ["@types/*"]
        }
    }
}

Next, make sure to place the necessary declaration files in the @types/ directory:

declare module 'missing-module' {
    // your declarations here
}

If you're looking to create a declaration file, make sure to save it with the .d.ts extension.

Include this file name in the tsconfig.json file under the include key:

  "include": [
    "src",
    "index.d.ts"
  ]

By executing the following command, you can easily fix the issue at hand:

npm install --save @types/node-forge

For additional information, please visit this link:

https://www.npmjs.com/package/@types/node-forge

My personal approach is to set up the dependencies as development dependencies. While the suggestion of turning off implicit type checking may work, it prevents me from fully utilizing the benefits of strongly typed code. To resolve this, simply add the "--save-dev" flag to all @types module installations.

Whenever I transition to my laptop, I always make it a point to execute commands like git fetch, git pull, and npm install. Recently, I encountered an error related to one of the packages, specifically ts-pattern.

To resolve this issue, I decided to perform a npm clean-install operation. It seems like there was a glitch in the package-lock.json file or something similar.