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.

Sign up for GitHub

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

Jump to bottom

Unable import in TypeScript since v5+ #109

Open
andy1547 opened this issue Mar 22, 2022 · 10 comments · May be fixed by #130
Open

Unable import in TypeScript since v5+ #109

andy1547 opened this issue Mar 22, 2022 · 10 comments · May be fixed by #130

Comments

@andy1547
Copy link

andy1547 commented Mar 22, 2022 •
edited
Loading

Using the latest v5.2.0 package (containing JS and TypeScript index.d.ts), I've tried the following:

Importing with ESM default:

import Long from "long";
import Long from "long/umd";
// these statements give the following error:
TS1259: Module '"node_modules\\long\\index"' can only be default-imported using the 'allowSyntheticDefaultImports' flag

Importing everything with import *, I use this syntax to import CommonJs modules that export a single object (without default) e.g. import * as jquery from 'jquery':

import * as Long from "long";
import * as Long from "long/umd";
TS2497: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.

When I change my TypeScript module output from ESM to AMD (AMD output permits the require syntax), it will compile:

import Long = require("long");
import Long = require("long/umd");

// unfortunately I'm unable to use this syntax with ESM output, which is a blocker for us: 
TS1202: Import assignment cannot be used when targeting ECMAScript modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from "mod"', or another module format instead.

It's also possible to get this working with v4.0.0 with @types/long v4.0.1 (separate package before types were bundled in v5+) when using the import * as Long from "long" syntax when module output is ESM.

It seems strange to me that the TypeScript declaration exports with = but the JavaScript exports with an ESM default. I suspect the mix/matching of these styles causes the error. The ESM JS/TS should stick to ESM imports/exports and the UMD JS/TS should stick to UMD exports.
@lovell lovell mentioned this issue May 3, 2022
Closed
@sonicoder86 sonicoder86 mentioned this issue May 5, 2022
Closed
@owstron
Copy link

owstron commented Sep 12, 2022

I was able to import from version 5.0.1 which had export default Long by using import Long from 'long', I could not import it either via import * as Long from 'long', import { Long } from 'long' or import Long from 'long'. With 5.2.0 I had to use import Long = require('long').
Btw, my TsConfig setting is set to { module: 'ESNext' }

@DavidSouther DavidSouther mentioned this issue Sep 23, 2022
Open
@smaye81 smaye81 mentioned this issue Nov 10, 2022
Merged
smaye81 added a commit to bufbuild/protobuf-es that referenced this issue Nov 11, 2022
@smaye81
Improve TS compatibility checks (#296)
6372cde 
This makes the TS compatibility checks a bit more robust by fixing a few
issues in the codebase as well as changing our TypeScript test configs
to include all files rather than just the test files.

Note that the `long` package needed downgraded to `5.0.1` (and pinned to
patches only) because of an issue in that library with 5.2 and above.
See this issue: dcodeIO/long.js#109
This was referenced Dec 7, 2022
Merged
Closed
@enricoangelon enricoangelon mentioned this issue Jan 14, 2023
Open
@creatorapp
Copy link

Is there any fix coming in for this? Looks like google packages like firebase-admin and firebase-tools depend on this module. With the following tsconfig.json,

  "compilerOptions": {
    "experimentalDecorators": true,
    "esModuleInterop": true,
    "module": "ESNext",
    "target": "esnext",
    "moduleResolution": "nodenext",
    "allowJs": true,
    "strict": false,
    "sourceMap": true,
    "outDir": "dist",
    "rootDir": "./src",
    "emitDecoratorMetadata": true,
    "types": ["reflect-metadata"],
    "lib": ["es6", "dom"]
  },
  "lib": ["es2015"],
  "include": ["src/**/*.ts"]

I continue to get the error:

node_modules/@grpc/proto-loader/build/src/index.d.ts:22:23 - error TS1471: Module 'long' cannot be imported using this construct. The specifier only resolves to an ES module, which cannot be imported with 'require'. Use an ECMAScript import instead.

22 import Long = require('long');

@russellsteadman
Copy link
Contributor

The source of this error is:

long.js/index.d.ts

Line 446 in 3cea40d

export = Long; // compatible with `import Long from "long"`

This is only compatible with synthetic ES modules being exported as CommonJS. For true ES modules this should be:

export default Long;

See the TypeScript documentation which states that separate type definitions can be specified (scroll to the code bubble right after the "The new support works similarly with import conditions." paragraph).

@russellsteadman russellsteadman mentioned this issue Apr 15, 2023
Merged
@dcodeIO
Copy link
Owner

dcodeIO commented Apr 15, 2023

Thanks @russellsteadman for the PR! There should be a new release at 0 UTC. Lmk if there are remaining issues with the fix in place.

@magiclen
Copy link

magiclen commented Apr 16, 2023 •
edited
Loading

v5.2.2 shows Module not found: Error: Default condition should be last one when webpack is running. But v5.2.1 does not have this error.

I'm using ESM + Webpack + TS.

@magiclen magiclen mentioned this issue Apr 16, 2023
Closed
@dcodeIO dcodeIO mentioned this issue Apr 16, 2023
Merged
@dcodeIO dcodeIO pinned this issue Apr 16, 2023
@dcodeIO
Copy link
Owner

dcodeIO commented Apr 16, 2023

Reordered in v5.2.3, lmk!

@rjwalters rjwalters mentioned this issue Jul 22, 2023
Closed
@SimplyLinn SimplyLinn linked a pull request Nov 22, 2023 that will close this issue
Open
@nhuethmayr
Copy link

Any news on this?

@dotboris dotboris mentioned this issue Mar 26, 2024
Open
@JustDoItSascha
Copy link

No updates on this for 3 months?

@gokeji
Copy link

gokeji commented Jul 4, 2024

If it helps anyone, I was able to get around this issue by using patch-package as a post-install step.

The file /node_modules/long/umd/index.d.ts b/node_modules/long/umd/index.d.ts was updated to:

// Declare a module for 'long'
declare module "long" {
  const Long: any; // Use 'any' or provide a more specific type if available
  export = Long;
}

@kirillgroshkov
Copy link

My recipe for patch-package is this:

diff --git a/node_modules/long/umd/index.d.ts b/node_modules/long/umd/index.d.ts
index c623535..59c28bb 100644
--- a/node_modules/long/umd/index.d.ts
+++ b/node_modules/long/umd/index.d.ts
@@ -1,2 +1,3 @@
+// @ts-expect-error this fixes the tsc compilation issue and allows us to remove `skipLibCheck` from tsconfig
 import Long from "../index.js";
 export = Long;

joao-vasconcelos added a commit to carrismetropolitana/api that referenced this issue Sep 11, 2024
@joao-vasconcelos
Add skipLibCheck to fix bug dcodeIO/long.js#109
1f57827 
More info: dcodeIO/long.js#109
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
10 participants
@gokeji @dcodeIO @russellsteadman @kirillgroshkov @magiclen @JustDoItSascha @andy1547 @owstron @nhuethmayr @creatorapp