Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error TS2307: Build:Cannot find module '@mesh/core' or its corresponding type declarations. #182

Closed
matbech opened this issue Dec 18, 2023 · 3 comments

Comments

@matbech
Copy link

matbech commented Dec 18, 2023

I get the following compiler errors with Visual Studio

node_modules\@meshsdk\core\dist\common\constants.d.ts(1,21): error TS2307: Build:Cannot find module '@mesh/core' or its corresponding type declarations.
node_modules\@meshsdk\core\dist\common\constants.d.ts(2,31): error TS2307: Build:Cannot find module '@mesh/core' or its corresponding type declarations.
node_modules\@meshsdk\core\dist\common\contracts\fetcher.d.ts(1,100): error TS2307: Build:Cannot find module '@mesh/common/types' or its corresponding type declarations.

If I replace all the @mesh imports in constants.d.ts with relative paths:

import { csl } from '../core';

it does work as expected.

Another workaround is to add a module alias as following to tsconfig.json:

	"compilerOptions": {
		"paths": {
			"@mesh/*": [ "./node_modules/@meshsdk/core/dist/*" ]
		}
	},

But it might be better to relative paths inside the .ts files.

@dchambers
Copy link

The use of out-of-band module aliasing (i.e. @mesh/*) also prevents Deno users from being able to click through to the type of interest within their IDE in cases where those types are imported using links which depend on these aliases. For example, within transaction.service.d.ts:

import type {
  Action,
  Asset,
  Data,
  Era,
  Mint,
  Protocol,
  PlutusScript,
  PoolParams,
  Recipient,
  Token,
  UTxO,
} from "@mesh/common/types";

This may affect other tooling too, since the aliasing config has to be specified out-of-band (outside ESM) separately for each tool that needs it; hence why you have separate config for this in tsconfig.json and vite.config.js.

@dchambers
Copy link

So I just switched to Node.js so I could use @meshsdk/mesh-csl, and I hit the same aliasing issues when using tsc to compile my TypeScript code. The solution I ended up going with was to have tsc ignore the library errors with:

"skipLibCheck": true,

@HinsonSIDAN
Copy link
Member

Packaging has been updated entirely since V1.6, please re-open if issue persists.

Side note, everything is now packaged in @meshsdk/core, if you need some csl specific function, now it is exported at @meshsdk/core-csl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants