mobily / ts-belt

🔧 Fast, modern, and practical utility library for FP in TypeScript.
https://mobily.github.io/ts-belt
MIT License
1.12k stars 31 forks source link

The requested module '@mobily/ts-belt' is a CommonJS module #117

Open timoxley opened 3 months ago

timoxley commented 3 months ago
mport { A } from '@mobily/ts-belt';
         ^
SyntaxError: Named export 'A' not found. The requested module '@mobily/ts-belt' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@mobily/ts-belt';
const { A } = pkg;

Trying to build a project using ts-belt with pkgroll and it's giving me the above error, no matter what tsconfig settings I supply for target/module.

Only seems to affect ts-belt, I'm not sure exactly what the problem is, but perhaps you know?

JUSTIVE commented 2 months ago

I use ts-belt for almost every project but have never seen that. can you share your configurations(package.json/tsconfig)?

dsherret commented 1 month ago

It occurs when importing the module from ESM thereby using the package's ESM export, which is broken.

> touch package.json
> npm install @mobily/ts-belt@3.13.1
> echo 'import * as test from '@mobily/ts-belt'; console.log(test)' > main.mjs
> node main.mjs
(node:39952) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
V:\scratch\node_modules\.deno\@mobily+ts-belt@3.13.1\node_modules\@mobily\ts-belt\dist\esm\index.js:1
import { pipe } from "./pipe.js";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at wrapSafe (node:internal/modules/cjs/loader:1376:18)
    at Module._compile (node:internal/modules/cjs/loader:1405:20)
    at Module._extensions..js (node:internal/modules/cjs/loader:1544:10)
    at Module.load (node:internal/modules/cjs/loader:1275:32)
    at Module._load (node:internal/modules/cjs/loader:1091:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:212:19)
    at cjsLoader (node:internal/modules/esm/translators:318:5)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:258:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:262:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:474:24)

Node.js v22.3.0
> node --experimental-detect-module main.mjs
node:internal/modules/esm/resolve:254
    throw new ERR_UNSUPPORTED_DIR_IMPORT(path, fileURLToPath(base), String(resolved));
          ^

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import 'V:\scratch\node_modules\.deno\@mobily+ts-belt@3.13.1\node_modules\@mobily\ts-belt\dist\esm\Function' is not supported resolving ES modules imported from V:\scratch\node_modules\.deno\@mobily+ts-belt@3.13.1\node_modules\@mobily\ts-belt\dist\esm\index.js
    at finalizeResolution (node:internal/modules/esm/resolve:254:11)
    at moduleResolve (node:internal/modules/esm/resolve:920:10)
    at defaultResolve (node:internal/modules/esm/resolve:1119:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:541:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:510:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:240:38)
    at ModuleJob._link (node:internal/modules/esm/module_job:126:49) {
  code: 'ERR_UNSUPPORTED_DIR_IMPORT',
  url: 'file:///V:/scratch/node_modules/.deno/@mobily+ts-belt@3.13.1/node_modules/@mobily/ts-belt/dist/esm/Function'
}

Node.js v22.3.0
adrian-gierakowski commented 1 month ago

just got bitten by the same issue the following gives me an error in node 22.8.0

import { A, D, F } from '@mobily/ts-belt'

the worst thing is that it typescript compiles it without complaining, which is probably due to types being partially broken as indicated here

https://arethetypeswrong.github.io/?p=%40mobily%2Fts-belt%403.13.1

image

adrian-gierakowski commented 1 month ago

seems like this is fixed in latest RC

btw. it's not too difficult to patch it in 3.x but it seems like there are no breaking changes in 4.x so simply upgrading to it is the best option

JUSTIVE commented 2 days ago

I've been using 4.0.0rc for a year and a half, and I'm sure it's stable.