First of all, Typescript isn’t a standard, much less a universal standard - it’s a fairly patchy implementation of strong typing over JavaScript, created by a private corporation. If you’re going to write strongly typed JavaScript, it’s probably the best option, though not the only option. If you want a strongly typed, functional language, and are not wedded to JavaScript, it’s definitely not the best option.
Strong typing is an incredibly powerful tool,and will make your life easier, once you wrap your head around it, but it isn’t the only way to go, for all projects. There are definitely some (typically small) projects that benefit from a more dynamic typing system.
I am not really sure what you are saying about unit tests. It sounds like you are saying you think you need unit tests to assure types on the JavaScript level, even when working in typescript. That’s not the case. You can trust the compile-time type system, if you type your code. You still should have unit tests, of course, but you really don’t need unit tests that check that the types are what your typescript typing says they are. In fact, the more skilled you get at building good types, the fewer tests you’ll need. They’re always a compliment, the goal isn’t to eliminate tests at all, but you will get better safety with less testing.
Typescript probably shouldn’t be doubling the amount of code. This sounds like you might be adding a lot of redundant type aliases, or specifying types that should be inferred. I’m not sure, I’d have to see the code.
You also might want to look at your toolchain. Are you doing a bunch of coding, then running tsc and looking at the results? Or do you have an editor set up that can show you typescript errors and suggested completion in real time? It makes a huge difference, having a toolchain that really supports rapid, iterative, strongly typed development.
So the biggest issue is the project relies extremely heavily on a third party API service, and since the data is received over said service, typescript is unable to infer what the objects the API is sending is because it sends during runtime, to get around this I have to define everything that I expect that the library is going to have to handle that would be Recieved, since any object that the API is going to return is just going to have a type of any if it’s not defined, this on top of the fact that the API has stated that the data being sent should not be relied on for being accurate and types may change randomly(usually it does not but it has happend, it sucks but out of my control) means that I generally also have to have a function level test the data when it’s received to make sure that the value is being supplied are the correct type and are formatted in a way that the library can still understand it. Which means that it’s able to catch any inconsistency of typing before it would be processed anyway, and would either warn or throw depending on how important the function is to actual operation.
The reason why I would call it standard is because it seems like basically anywhere you look if you are using node, you’re using typescript they go hand in hand it seems as of the last two or three years, but honestly I’ve never really understood the benefit of, I’ve always thought it was a fairly standard to have at the beginning of a function the documentation of what each perimeter should be unless it is easily verified by looking at it.
As for my setup, it’s not very advanced it’s just Sublime Text with linter hooked to it, which does tell me on save if there’s a typescript error or if I formatted something wrong, but again even if one did happen to slip through that it would fail during the testing phase due to the fact that it would throw at the function level.
My opinion of my experience with typescript has been that it’s great if everything is operated in house, but the second you start having to deal with stuff that comes from an external source any advantage of the check just seems not worth the extra effort to make sure typescript works right.
OK, so, a lot here.
First of all, Typescript isn’t a standard, much less a universal standard - it’s a fairly patchy implementation of strong typing over JavaScript, created by a private corporation. If you’re going to write strongly typed JavaScript, it’s probably the best option, though not the only option. If you want a strongly typed, functional language, and are not wedded to JavaScript, it’s definitely not the best option.
Strong typing is an incredibly powerful tool,and will make your life easier, once you wrap your head around it, but it isn’t the only way to go, for all projects. There are definitely some (typically small) projects that benefit from a more dynamic typing system.
I am not really sure what you are saying about unit tests. It sounds like you are saying you think you need unit tests to assure types on the JavaScript level, even when working in typescript. That’s not the case. You can trust the compile-time type system, if you type your code. You still should have unit tests, of course, but you really don’t need unit tests that check that the types are what your typescript typing says they are. In fact, the more skilled you get at building good types, the fewer tests you’ll need. They’re always a compliment, the goal isn’t to eliminate tests at all, but you will get better safety with less testing.
Typescript probably shouldn’t be doubling the amount of code. This sounds like you might be adding a lot of redundant type aliases, or specifying types that should be inferred. I’m not sure, I’d have to see the code.
You also might want to look at your toolchain. Are you doing a bunch of coding, then running tsc and looking at the results? Or do you have an editor set up that can show you typescript errors and suggested completion in real time? It makes a huge difference, having a toolchain that really supports rapid, iterative, strongly typed development.
So the biggest issue is the project relies extremely heavily on a third party API service, and since the data is received over said service, typescript is unable to infer what the objects the API is sending is because it sends during runtime, to get around this I have to define everything that I expect that the library is going to have to handle that would be Recieved, since any object that the API is going to return is just going to have a type of any if it’s not defined, this on top of the fact that the API has stated that the data being sent should not be relied on for being accurate and types may change randomly(usually it does not but it has happend, it sucks but out of my control) means that I generally also have to have a function level test the data when it’s received to make sure that the value is being supplied are the correct type and are formatted in a way that the library can still understand it. Which means that it’s able to catch any inconsistency of typing before it would be processed anyway, and would either warn or throw depending on how important the function is to actual operation.
The reason why I would call it standard is because it seems like basically anywhere you look if you are using node, you’re using typescript they go hand in hand it seems as of the last two or three years, but honestly I’ve never really understood the benefit of, I’ve always thought it was a fairly standard to have at the beginning of a function the documentation of what each perimeter should be unless it is easily verified by looking at it.
As for my setup, it’s not very advanced it’s just Sublime Text with linter hooked to it, which does tell me on save if there’s a typescript error or if I formatted something wrong, but again even if one did happen to slip through that it would fail during the testing phase due to the fact that it would throw at the function level.
My opinion of my experience with typescript has been that it’s great if everything is operated in house, but the second you start having to deal with stuff that comes from an external source any advantage of the check just seems not worth the extra effort to make sure typescript works right.