Skip to content

.d.json.ts file (allowArbitraryExtensions) not working correctly when importing from ESM file with node16/nodenext module settingΒ #57229

Open

Description

πŸ”Ž Search Terms

allowArbitraryExtensions, import, JSON, d.json.ts, nodenext, node16, mjs, mts, "type": "module"

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries

⏯ Playground Link

https://codesandbox.io/p/devbox/json-import-bug-frj89p

πŸ’» Code

tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "resolveJsonModule": true,
    "allowArbitraryExtensions": true,
    "noImplicitAny": true
  }
}

foo.json

["foo", "bar", "baz"]

foo.d.json.ts

// In this contrived example we're declaring it as a tuple since TS otherwise infers it as string[]
declare const data: ["foo", "bar", "baz"];
export default data;

index.mts, or index.ts with "type": "module" in package.json

import data from "./foo.json" with { type: "json" };

// Apparently not an array, these all error!
const x = data satisfies any[];
data.forEach((item) => console.log(item));
type Item = (typeof data)[number];

// TS thinks it lives on .default
const x2 = data.default satisfies any[];
data.default.forEach((item) => console.log(item));
type Item2 = (typeof data.default)[number];

πŸ™ Actual behavior

The compiler/intellisense thinks the JSON value lives on the .default property, as if the import were a CommonJS/"synthetic" ES module.

πŸ™‚ Expected behavior

It should know that the "base" (actual default) import holds the JSON value, which is the behaviour when there isn't a .d.json.ts file present and most importantly the runtime behaviour.

Additional information about the issue

I tried renaming to *.d.json.mts but then the file simply doesn't get picked up.

The motivation for using this feature in the first place is because I'm importing a big JSON array of objects that causes a long delay every time autocompletion is invoked or something is hovered and generally makes things unbearably sluggish, and fails to infer the type anyway. Some people reporting the same thing in this issue: #48364

Side note: if you're messing around in the CodeSandbox sometimes the intellisense won't update unless you do something like modify the import path to trigger it. Also if you use the terminal you should use npx tsc because the globally installed version (at the time of writing) is 5.2 which complains about import attribute syntax. So I recommend testing locally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Breaking ChangeWould introduce errors in existing codeBugA bug in TypeScriptFix AvailableA PR has been opened for this issueRescheduledThis issue was previously scheduled to an earlier milestone

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions