After conversion from typescript to javascript

Code_Crash 0
Viewed 40

I tried to clear my doubts regarding TypeScript, but not able to clarify it well, what I understand, TypeScript is a strict syntactical superset of JavaScript, which makes our code a lot better, clean, and meaningfully as we can use different types to define our object, variables, and classes.

however, what happens if we are using JavaScript code, which got converted from the TypeScript code, to perform a certain task? as far as I understand, it does not guarantee for type restriction anymore.

so couple of pointers here which I understood (maybe I'm wrong or not understood correctly):

  • TypeScript only allows us to code better.
  • Does not gives the guarantee after conversion.
  • It gives us a .d.ts declaration file which we can use in any other TypeScript project. (it's useless in JS?)

Please see the below example:

TypeScript Code:

// Takes number only
const log = (a: number) => {
    console.log(a);
}

// NOTE: Passing string in ts showing/highlighting the issue, 
// however after conversion from TS to JS, 
// we can pass a string to the log method.
log('a');

Got Converted Into JavaScript Code as below:

"use strict";
// Takes number only
const log = (a) => {
    console.log(a);
};
// NOTE: Passing string in ts showing/highlighting the issue, 
// however after conversion from TS to JS, 
// we can pass a string to the log method.
log('a');

If anyone knows, can you please explain if this is a valid understanding?

If yes, I was planning to work on some small library, which will help us to assert the object, classes, or variables regardless of TypeScript or JavaScript, when I thought to work on this, I realized we already have TypeScript.

Please excuse my typos.

Thanks.

tsc typescript javascript
3 Answers

The benefit of TypeScript is when those who are using code created from TypeScript (whether compiled or not) are using a type-aware system as well. For example:

  • You distribute a library in TypeScript. Others consume the library with their own TypeScript code as well, and will see warnings if they try to do something unsafe (such as log('a');)
  • You create a library in TypeScript and distribute it in JavaScript as well as a .d.ts file that notes the typings for its exports. Others consume the library with their own TypeScript and the same benefits apply.
  • You create a library like either of the above, and others do not use TypeScript to consume it - but they're using an IDE that supports being type-aware and has settings set up to make sense of TypeScript typings (such as VSCode). While they won't have a full TypeScript compiler, they'll at least be able to see what sorts of types different values are, and may receive warnings in their IDE if they try to do something obviously wrong like log('a').
  • Same as above, but a consumer of the library is writing only in JavaScript and is not using a type-aware IDE - for example, say they're writing in Notepad. They receive no benefits from you having written the library in TypeScript because they won't see any warnings, and will be able to do log('a'); unsafely.
CertainPerformance0

You're right that Typescript doesn't offer any runtime type safety, because it never runs; all TS code is always converted to JS before running. That doesn't really subtract from its value, though!

Whenever you write a program in Typescript, every case covered by your code is typed correctly. This means that whenever you attempt to do what you did above (put a string into a numeric function), it will show you an error, and hopefully not transpile. So as long as you always pay attention to warnings and errors in your editor, your code will (practically) have runtime type safety.

There are some exceptions, though. Whenever we receive objects from external sources (e.g. npm-packages or API-calls), we can't always be sure that these objects have the shape we expect them to. Maybe the API changed or the npm-package has no types. In those cases it might be tempting to use the any-type everywhere.

Don't use any. You might as well write JS at that point.

If your data is of an unknown format, use the unknown type, then do checks on the data until you can either coerce it into a type or throw an error.

tl;dr: TS only offers compiletime type safety, but that's still pretty good!

useruPXK0

Basically, your understanding is already pretty right. To answer some of your questions:

TypeScript doesn't make any guarantees about your code to run. You can use "any" casts or a library with non strict types or some native methods that would fallback to the "any" type, if the types could not be determined by TypeScript itself.

TypeScript is most importantly a compiler. It can compile your code, which is using maybe already features that don't exist in older versions of Javascript to be compatible with this older version of Javascript. And in addition - and this is the most outstanding feature - it supports a certain build-in type syntax on top of that, that can be checked and cleanly removed when compiling your code.

When you are building libraries, you can and should, also make use of the declaration files (*.d.ts). These are files with a special syntax, that are only used by TypeScript to ignore certain other files or add global type definitions. E.g. having a file "foo.js" and close to it "foo.d.ts", TypeScript will read the "foo.d.ts" instead. This is how packages should be published, so the different build tools and also projects not using TypeScript are supported when using your library.

Viktor Luft0
Related