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

JSON files generate declarations #34761

Closed
ark120202 opened this issue Oct 28, 2019 · 10 comments
Closed

JSON files generate declarations #34761

ark120202 opened this issue Oct 28, 2019 · 10 comments
Assignees
Labels
Bug A bug in TypeScript

Comments

@ark120202
Copy link

TypeScript Version: 3.8.0-dev.20191026

Search Terms: json, declarations

Code

// tsconfig.json
{
  "include": ["src/**/*", "src/**/*.json"],
  "compilerOptions": {
    "rootDir": "src",
    "outDir": "dist",
    "resolveJsonModule": true,
    "declaration": true
  }
}
// src/test.json
{}

Expected behavior:

dist
└── test.json

(same as on v3.6.4)

Actual behavior:

dist
├── test.d.ts
└── test.json

Playground Link:

Related Issues: #34676

@sheetalkamat
Copy link
Member

#32372 enables declaration for .js, .jsx and .json files

@ark120202
Copy link
Author

Thanks, I haven't noticed that it enabled it for .json files as well. Shouldn't it be named test.json.d.ts instead of test.d.ts though? Since json files can be imported only with extension, generated declarations would always reference it as ./test.json, which wouldn't find test.d.ts. Another solution there would be to trim .json extension for declaration resolution, like .js, but there is an another problem it causes - it's not allowed to have .ts and .json files with the same name anymore.

@RyanCavanaugh RyanCavanaugh added the Bug A bug in TypeScript label Oct 30, 2019
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 3.7.2 milestone Oct 30, 2019
@fatcerberus
Copy link

Hmm, Node at least will load .json even without an extension:
https://nodejs.org/api/modules.html#modules_all_together

LOAD_AS_FILE(X)
1. If X is a file, load X as JavaScript text.  STOP
2. If X.js is a file, load X.js as JavaScript text.  STOP
3. If X.json is a file, parse X.json to a JavaScript Object.  STOP
4. If X.node is a file, load X.node as binary addon.  STOP

@weswigham
Copy link
Member

Yah, our filename generation assumes the same extension stripping behavior on import for all extensions. I'm... Conflicted? On generating a obj.json.d.ts instead of obj.d.ts. I don't want to special case it. In theory, it shouldn't be treated any differently than .ts or .tsx or any other supported extension; but our implementation of json file imports doesn't seem to have the same resolution behaviors that normal imports do (which is odd, since .json is lIke any other supported extension in node). Thing is, any non-technical reason one has to justify generating a obj.json.d.ts also justifies generating file.ts.d.ts and the like (as you're equally capable of having .ts and .js and .tsx and .jsx files of the same name side-by-side)... And I really don't think we wanted to start doing that. Because of that, I'm inclined to want to introduce extension stripping declaration file lookup for json imports, just like what other extensions do, instead... (Despite knowing that yes, it prevents you from having multiple files with the same name in the same place - I don't think it's been a problem for .tsx and .ts, so I'd hope people can work with .json the same way)

@fatcerberus
Copy link

Point against file.ts.d.ts specifically: TS actually errors on imports ending in .ts.

@raymondfeng
Copy link

@weswigham Maybe at least there should be a flag to disable emitting declaration files for *.json?

raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Nov 5, 2019
raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Nov 5, 2019
raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Nov 7, 2019
raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Nov 7, 2019
raymondfeng added a commit to loopbackio/loopback4-example-shopping that referenced this issue Nov 8, 2019
raymondfeng added a commit to loopbackio/loopback4-example-shopping that referenced this issue Nov 9, 2019
raymondfeng added a commit to loopbackio/loopback-next that referenced this issue Nov 11, 2019
raymondfeng added a commit to loopbackio/loopback4-example-shopping that referenced this issue Nov 11, 2019
@thovden
Copy link

thovden commented Dec 20, 2019

I'm in a Catch 22 situation here, and would really appreciate a way out - e.g., a boolean flag to turn off declaration output for json - e.g., declarationJson:

  • declaration: false for my projects that use JSON is not an option, because Composite projects may not disable declaration emit. Also, I want the types.
  • Renaming the JSON is not an option, because the framework (loopback@^3) requires the model and implementation files to have the same name.
  • Setting resolveJsonModule: false will require to re-introduce the Gulp hell I have now been able to get out of to move JSON files to the dist directory.

@weswigham - I understand there are many considerations to take into account here, but some way to deal with this issue would be nice.

@wschella
Copy link

Am I correct in thinking this also poses a problem in projects that don't specify an outDir? For some foo.json a foo.d.ts get's generated. Unlike .d.ts files generated from .ts files, this new foo.d.ts is included during compilation. Generating an error like this:

error TS5055: Cannot write file '/foo/bar/package/lib/foo.d.ts' because it would overwrite input file.

@weswigham
Copy link
Member

It's the same thing the happens when you have both a foo.ts and a foo.tsx or foo.js in the same place in a build, yes.

@weswigham
Copy link
Member

AFAIK this was already done in #36066, so I'm closing this.

musaevonline added a commit to musaevonline/web-constructor that referenced this issue Mar 14, 2021
djambo05 added a commit to djambo05/groove that referenced this issue Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript
Projects
None yet
Development

No branches or pull requests

9 participants