X Tutup
The Wayback Machine - https://web.archive.org/web/20220924070228/https://github.com/microsoft/TypeScript/issues/35470
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

Ability to disable TS8010: 'types' can only be used in a .ts file. #35470

Open
brandonpearcy opened this issue Dec 3, 2019 · 16 comments
Open
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@brandonpearcy
Copy link

brandonpearcy commented Dec 3, 2019

Search Terms

TS8010
TS 8010
types can only be used in a .ts file
'types' can only be used in a .ts file

Suggestion

Ability to disable TS8010: 'types' can only be used in a .ts file. Type annotations could simply be ignore by tsc when compiling a .js file.

Use Cases

I work in a JS / TS blended codebase. My team uses WebStorm as our IDE, and it supports type annotations in .js files. When a variable/param is typed, it provides type-specific autocompletion. As you can imagine, that's quite powerful when working in a JS environment. Consequently, we have thousands of type annotations throughout our JS files. We would like to add allowJs:true to our tsconfig.json, however tsc throws an error for every type annotation in each JS file.

Checklist

My suggestion meets these guidelines:

  • [ x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [ x ] This wouldn't change the runtime behavior of existing JavaScript code
  • [ x ] This could be implemented without emitting different JS based on the types of the expressions
  • [ x ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • [ x ] This feature would agree with the rest of TypeScript's Design Goals.
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Dec 5, 2019

Super confused here. Why is the file extension .js if it contains TypeScript-specific syntax?

@brandonpearcy
Copy link
Author

brandonpearcy commented Dec 5, 2019

I don't think this anywhere ideal; more of an accident of history. I'm very much open to ideas on how to get out of this mess! Offering a flag to disable TS8010 was just the first idea that came to mind. :)

A little more context if it's helpful:
(1) The TS specific syntax is being stripped before the JS code reaches production. This is a React Native codebase. The JS and TS all gets translated and bundled together by the Metro JS bundler. I checked the final output bundle, and it seems that Metro throws away TS type annotations.
(2) Regarding developer experience: even if the file extension is .js WebStorm will handle TypeScript type annotations and provide auto-completion suggestions. This is obviously very nice, from a JS developer's perspective.

Considering the above two points, we have ended up with A LOT of TS type annotations in .js files in our codebase.

Our goal is to migrate more of the codebase to TypeScript, and I am under the impression that the right way to go about doing this is to add allowJs to our tsconfig.json so that JS libraries are included in the output of tsc. However, at this moment, we're running into thousands of TS8010 errors.

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Dec 10, 2019
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Dec 10, 2019

I'm still unclear why you don't rename .js to .ts, but the rest of the scenario makes sense

@zenz
Copy link

zenz commented Mar 27, 2020

@RyanCavanaugh. In react-native .js file combines javascript and css together, change file name to .ts creates more problems then switch ts8010 syntax checking off.

@ValentinH
Copy link

ValentinH commented Apr 9, 2020

This could also be a valid use case for me. Indeed, I'm migrating an app from Flow to Typescript.

Right now, I'm using allowJs: true in my config and it enables me to import JS modules written in Flow into a TS modle with a working type-check in VSCode. However, if I run tsc --noEmit to ensure that my ts files are valid, I get tons of TS8010 errors.

Being able to disable this during the migration would really help us.

@captainamerican
Copy link

captainamerican commented Apr 30, 2020

You can't use ts-node with typescript files in a node module because node 13+ is stupid anal about file extensions. So you rename the file .js and use allowJS = true. The last step is ignoring this particular warning.

@mudrila
Copy link

mudrila commented Aug 14, 2020

You can't use ts-node with typescript files in a node module because node 13+ is stupid anal about file extensions. So you rename the file .js and use allowJS = true. The last step is ignoring this particular warning.

I believe real Captain wouldn't say something like node 13+ is stupid anal about file extensions 😄

@dmassissa
Copy link

dmassissa commented Sep 27, 2020

i use this link and help me fix this issues
https://www.youtube.com/watch?v=UQV2HMQZK4o

or this but is some video

https://www.facebook.com/watch/?v=2782095745399197&extid=T54ZcHrD4BPCy62c

@PinkaminaDianePie
Copy link

PinkaminaDianePie commented Oct 8, 2020

This issue is so annoying. We even have @ts-check comment to say that the file should be type-checked but it doesn't allow us to use type annotations :D

@Eli-Nathan
Copy link

Eli-Nathan commented Dec 7, 2020

I'm seeing this issue and it's making things super tough to migrate from Flow to TS.
My codebase has some Flow type annotations that we need to sit alongside the TS ones while we slowly migrate but as the Flow annotations are in .js files, I get hundreds of these errors.

@alexkrolick
Copy link

alexkrolick commented Dec 21, 2020

I am in a similar boat with Flow => TS migration. The ideal configuration during the migration is checkJs: false, allowJs: true, so that we can import JS files (with Flow types) into the TS files. But tsc give me thousands of errors for Type annotations can only be used in TypeScript files when it tries to see if the JS files contain TS code and mistakes the Flow annotations for TS. We can compile the code using Webpack, but can't do a static check in CI, with this setup.

@eric-burel
Copy link

eric-burel commented Oct 5, 2021

@alexkrolick same scenario, you say you can compile the code using Webpack, how do you do so? Because ts-loader is failing for me. I run Babel-loader as well with preset-flow so I don't get why the typings are still there.
Btw solutions for VS code are not enough for build time.

Edit: found out a way, using instead only Babel typeScript preset + an override to differentiate the build of .ts and .js, does the job so far.

@alexkrolick
Copy link

alexkrolick commented Oct 5, 2021

@eric-burel we got Webpack working the same way, via the Typescript plugin and a regex override for .ts/.tsx files

@nathanredblur
Copy link

nathanredblur commented Apr 11, 2022

will be nice make this even more powerful and allow us define an array of errors that we want to omit.
like tsc --excludeError TS8010

@apigon
Copy link

apigon commented Aug 17, 2022

Hi everyone! I ran in the same problem, currently migrating project from flow to TS. Have anyone found solution for that issue?

@apigon
Copy link

apigon commented Aug 19, 2022

I found workaround for that issue, definitely not ideal.
in tsconfig disable allowJs then add global.d.ts and add empty module declaration for whatever you need: declare module 'whateverModuleYouNeed'
Obvious drawback is that you need to add every file which you import to TS files, and maintain entries according to migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

X Tutup