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

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.

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

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.

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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.

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.

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.

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 😄

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

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

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.

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.

Alex Krolick (@alexkrolick)

Alex Krolick (@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.

Eric Burel (@eric-burel)

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

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

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

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.

how about

"exclude": [
    "src/**/*.js",
    "src/**/*.jsx"
  ]

in tsconfig?

how about

"exclude": [
    "src/**/*.js",
    "src/**/*.jsx"
  ]

in tsconfig?

I've read in other sources that this doesn't work because .js files imported by .ts files are still included anyway.

Navigation Menu

Repository navigation

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

Search Terms

Suggestion

Use Cases

Checklist

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Search Terms

Suggestion

Use Cases

Checklist

Activity

RyanCavanaugh commented on Dec 5, 2019

brandonpearcy commented on Dec 5, 2019

RyanCavanaugh commented on Dec 10, 2019

zenz commented on Mar 27, 2020

ValentinH commented on Apr 9, 2020

captainamerican commented on Apr 30, 2020

mudrila commented on Aug 14, 2020

domingosmassissa commented on Sep 27, 2020

PinkaminaDianePie commented on Oct 8, 2020

Eli-Nathan commented on Dec 7, 2020

alexkrolick commented on Dec 21, 2020

eric-burel commented on Oct 5, 2021

alexkrolick commented on Oct 5, 2021

nathanredblur commented on Apr 11, 2022

apigon commented on Aug 17, 2022

apigon commented on Aug 19, 2022

alcovp commented on Oct 8, 2022

timotgl commented on Apr 11, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions