I’m trying to learn TypeScript and running into a very annoying issue with the tool. This code is from an online tutorial
class Greeting {
greet():void {
console.log(“Hello World!”)
}
}
var obj = new Greeting();
obj.greet();
And it works just fine in a terminal with tsc and node commands. In VSC it throws this error
greet():void {
^
SyntaxError: Unexpected token ‘:’
I’ve search the settings for VSC and I’m not finding anything that looks related. For Pete’s sake, the tool is more problematic that the language!
I’ve wasted enough time on this so please tell me the magic that fixes this. While you’re at it, if there are any other settings, or whatever, that commonly trip up noobs please say what they are so I don’t have to keep coming back here to re-validate my noobiness.
Aha, it appears that VSC is running “node file.ts” which throws the same error in a terminal. I thought VSC would compile the code to a “.js” and run that but it appears not.
TypeScript is really just a superset of Javascript which adds “types” to the JS language and then TS actually will compile or convert/export out valid JS.
I would suggest starting out with the node.js tutorials and plain JS for some basics and then layer TS on the basic.
[EDIT] I specifically call out Node.JS tutorials as they are for server side/local JS processing where 99% of all other JavaScript tutorials are based around Web Development and are expected to be ran from a browser.
No, not out-of-the-box. The “easiest” way to run TS code is using webpack, even for locally executed code. It then allows for workflows to be automated and you can be more productive.
Before I answered you I built a new minimal dev-environment since my daily-use one has a lot of “special” things setup. Running first tsc and then node to run the .js file generated is fine for a start. For development “ts-node” could also be helpful, but it requires a complete project setup if launched from VSC. To just use it in the terminal, just install it with “sudo npm -i -g ts-node” and run eg. “ts-node greeting.ts”. This will transpile the .ts file to .js and then run it inside the VSC console.
You will want to setup tsconfig.json and configure the launch commands in “.vscode/launch.json” to run everything all at once when pressing F5. The video I linked to the other day does explain how to get the environment setup in order to get started.
What I will try to do as soon as I can find the time is create a small start-project to work with TS without targeting a web-application. If I don’t publish one within a week, remind me In the meantime, feel free to ask here. When developing inside our platform all these details are taken care of and there will be clear examples. For now I’ll have to see about getting that starter project ready.
Thanks, @markus. That’s helpful and I’ll give it a go. Since the only reason I have for learning TS is to prepare for your product environment I’m trying to start with the blessed tools and config.
@simplextech makes a good point and JS is not only at the heart of TS it’s what node-red runs on.
This is a really good beginners guide, thank you With that one I think there is no need for a starter project from me. I will still probably make one, but I’ll keep it in line with that guide so they can complement each other.
Then focus on that beginners guide from khalilstemmler.com. It’s a good start. That video course is a total of 15 hours and will go into depth on how to write TS, but it might be a lot to go for at once.
In reality I would step back from TypeScript and just browse around with JavaScript and toy around with node.js. Play with some basics and learn JS basics first. TS just adds on to JS so you really do need to know JS before you jump into TS.
I feel ya I’m still a noob with JS but getting more comfortable with it. The language itself isn’t too hard and a lot of it will come down to the “framework” of whatever platform you’re working with. Until there’s a API or full SDK for Collective Core we don’t know what API’s or modules or anything we’ll have to work.
Relax, step back and just tinker with JS basics and syntax of the language for now
Also in regards to that beginner guide, if you are using VSC, there is a live server extension that works very well and that you do not have to mess with building a NPM package to host the server. Also there are extensions for various browsers to integrate debugging into VSC with breakpoints in VSC, again after hosting a basic HTML instance, basically for console only in my experience so far. That video tutorial @markus listed is very good, although it guides you through the npm server not the live server extension like I am using.
Actually I was just thinking, it may be smart to create a thread of “Useful Extensions” for TS development using Visual Studio Code. Possibly even make a Oh-La Labs Extension pack, but not exactly sure what that entails.
I’m not sure I would agree here, it depends on your background. If you come from a strongly typed language, TS may very well be easier to get “right” than JS. There are many pitfalls when writing JS code which you may not even think about when coming from a strongly typed language. But yes, you do have a point, TS can be daunting at first, but it is also oh so rewarding once you get past the initial hurdles.
Even though I code JS well, I’ve never liked it, but I LOVE TS.
That’s a nice way of working with TS, I’ll have a look at it, though our workflows might not work 100% with that one.
All in all I’d say there is only one downside to the plugins and packages available for TS development: there’s so many of them and it can be hard to know what to choose Oftentimes there’s more than one excellent option, it just boils down to taste.
For those of us practicing/learning TS in preparation for development, what ECMAScript target version should we be looking at? Also, will decorators be heavily used to aid development either using FOSS libraries or in-house?
For locally executed code inside Node the target is es2018. For code that runs in the browser it’s different and may change depending on how far back we will end up supporting browsers. We will probably use one for Dashboards and another for the rest of the UI since what needs to be supported in terms of old hardware with old versions of browsers is different.
tool is more problematic that the language!
In the meantime, feel free to ask here. When developing inside our platform all these details are taken care of and there will be clear examples. For now I’ll have to see about getting that starter project ready.
With that one I think there is no need for a starter project from me. I will still probably make one, but I’ll keep it in line with that guide so they can complement each other.