I'm trying to write a game in Typescript but I am having a hard time setting things up.
I am using visual studio 2012 and I installed typescript 0.9.5.
What I want is to build an app/game like I would in C# or AS3, meaning using putting classes in seperate files and using modules to seperate/connect code. This would then compile to either a single file or some kind of require.js like solution (which I'm also not clear about).
But I have done a lot of research and ran in to a lot of hurdles.
-There are a lot of references to calling something like "tsc greeter.ts" but when I use this in the visual studio command window I get back "Command "tsc" is not valid." I tried adding the tsc folder to environment variables path, but this didn't change anything. So I can't really run it. Also I don't understand how tsc would know where greeter.ts is located.
-I'm confused between the "///" and the import statement. How do these factor in the structuring of an app?
-It seems there are a lot of ways to make a typescript app, which all have different requirements and code style and structure. Is there no standard way, or am I just mistaken and is there a good way to approach this?
So the main question is: How do I build a typescript app/game structured like a c# or AS3 app?
To answer just some of your question, you no longer need the /// reference like this:
/// <reference path="../typings/jquery.d.ts"/> This was used in earlier versions of typescript, however now it will find any typescript files in your project for you.
I don't think there is a 'standard' way to create a typescript project any more than there is C#, there are many design patterns and you will have to research the pros and cons of both and choose one.
You should also no longer need to run "tsc greeter.ts" to compile your code. It will compile on build of the project.
Related
I am learning the typescript also I am learning how to implement typescript in Node.js. Now, I have watched several videos and in those videos I found 2 methods to tie typescript with Node.js.
One is by using decorators and other is by using the generic method type(by defining request and response types - Usage of interfaces.)
The question is -> Which approach is preferable and which to use.(I am aware that there is no good or bad way I but still want to know the answer) In addition to performance, I also want to know which approach is easier for others to understand because in my opinion, both are quite difficult to understand.
Or is there any other and easier way to implement typescript with Node.JS?
There are some tools to help run TS in NodeJS, such as ts-node (https://www.npmjs.com/package/ts-node), but if you don't want to rely on that or, like me, can't figure out how to get it to work, you will want to have TS do what TS does, and transpile it to JS. Then in package.json, you'll want to have your start script reference the initial .js file.
To transpile TypeScript, simply use the command tsc if you have a tsconfig, or tsc [starting file] if you do not. This should compile the code first, and if compilation is successful, it will then transpile to JS in the designated folder.
In your package.json, ensure the command executed refers to the output folder's initial file. For example: "start": "node dist/app"
I have a TypeScript project that compiles down to a single JS file in /dist.
I have Jasmine tests, also written in TypeScript, that reference the various classes they test with references like:
/// <reference path="../../../src/script/classUnderTest.ts" />
When I compile the tests the TypeScript compiler pulls in all the referenced classes and I get a single JS file containing the test code and the code under test.
This actually works fine for just running the tests, but now I'd like code coverage too. From what I can tell, to get Istanbul to work I need to have the code under test separate from the test code. Also it would be nice to be testing exactly the JS file that will be live.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
(Or am I barking up the wrong tree entirely?)
Note, I am building this on a Mac, so from what I've read Chutzpah is not currently an option. I'm also currently using only npm scripts to do builds. I'd prefer to not bring in grunt or gulp unless it's absolutely necessary.
So, how can I get the type safety and autocomplete benefits of "/// reference" whilst using my compiled JS file when the tests are actually run?
Don't using TypeScript's --outFile option (few other reasons). Instead use modules e.g. --module commonsjs and a module loader e.g. webpack.
More
Browser quickstart : https://basarat.gitbooks.io/typescript/content/docs/quick/browser.html
Modules:
https://basarat.gitbooks.io/typescript/content/docs/project/modules.html
I have been working with TypeScript off and on for two years now. I am not an expert by any means, but I've spent some time in the eco-system: with VS2015 and node tools, with VSCode, and at the command line with tsc and typings (also used by VSCode).
And I have struggled with the correct way to get static typing and auto-complete etc in the code I've been writing.
I have a repo I maintain (EasyNodeQ) which was the start of my TypeScript experience and I sort of got that to a manageable place with ///reference and DefinitelyTyped. But any time I tried to use that within another project I had issues.
Things got a little better when I started using typings (rather than downloading the *.d.ts files myself) and especially with the ambient flag.
But I still have lots of issues trying to use that package within other projects. Depending on the approach I take, I get lots of Duplicate Identifier's, or module not found's or...
And this can range from Node definitions, to packages I use in both places (like node-uuid).
All I want to understand is this: how to I structure EasyNodeQ so that as I'm working on it, I get the static typings benefits of TypeScript but also have it be seamlessly included in other projects which can then also get these benefits?
Does that make sense?
The basic use cases are: npm install a package and get its typings, use my EasyNodeQ package and get its typings, work in a new project that uses EasyNodeQ and other packages and easily manage those typings.
Preferably in a VSCode or command line way...
This is with ES6 and the latest version of TypeScript (though an answer that works with ES5 would be nice - just not required).
I hope this makes sense. I've looked all over and I can't cobble together an answer that works.
UPDATE
I'm not convinced I've done this the "right" way, but it's working now so I thought I'd post the various things I've done (generally in the order I think they mattered and not inclusive because I may have forgotten some).
I hadn't npm'd the dependency package (easynodeq) and was just using a git url in the package.json - so I created a proper npm package and now install that package from npm
Instead of trying to use Bus.ts as both code and definition, I made Bus.js the "meat" of the npm, and built a Bus.d.ts file (also in the npm)
Embraced typings, using non-ambient definitions where possible and a mix of ambient definitions downloaded (via git) from DefinitelyTyped and "--ambient" definitions for the rest (because I'm still confused about the difference). The ambient definitions ended-up being the majority: node, express, serve-static, express-serve-static-core, mime, amqplib, when vs just bluebird and node-uuid, even though most of them were found by "typings search ..." Am I doing something wrong?
Modified package.json to also do "typings install"
Cleaned-up the git repo
There are several ways to make this work today. As you mentioned, using Typings works for definitions that aren't natively included in their NPM packages. For ones that do, you can using the typings field in package.json and it'll work with node module resolution. When you combine this together, you can publish packages that use both typings.json and relies on packaged typings - though this now forces your consumers to be using Typings to install the definitions. None of this, however, works with "ambient" definitions as they can not be namespaced properly.
This may be useful: https://github.com/typings/typings/blob/master/docs/faq.md#should-i-use-the-typings-field-in-packagejson. There's also dozens of examples I have using both workflows: https://github.com/blakeembrey/change-case/blob/master/package.json#L6 which uses node module resolution all the way down and https://github.com/blakeembrey/popsicle/blob/master/typings.json which uses Typings instead. Using Typings is only possible because it works to create namespaced ambient modules for you, but they won't conflict.
I had resigned myself to the fact that every require statement in Typescript had to be relative to the file you were typing in, but I recently discovered an application that does this differently and it confuses me. I was hoping someone with enough skill could explain how this is working to me.
The application in question is the new Raven DB HTML5 Studio, which uses typescript, you can find the whole application here:
RavenDB HTML5 Studio
When browsing its source code, I came across something interesting... if you go and look at many of the files; In specific the one I am looking at... app/viewmodels/deleteItems.ts, it has a reference at the top that reads..
import document = require("models/document");
but models/document isn't a path relative to deleteItems.ts, but this works. Can someone explain how this is happening? I'm linking you RIGHT to the exact files I'm talking about. This kind of behavior is littered all over this application.
app/viewmodels/deleteItem.ts
app/models/document.ts
This is exactly the kind of behavior I really wanted to try and emulate in my own code, since trying to keep all of the paths relative to the file I'm working in is a headache, but this program seems to be completely free of that requirement.
This doesn't necessarily involve RavenDB, but I am tagging it anyway, because perhaps someone who has read over the Raven repository will understand it and be able to answer.
Update
I am trying to mimic this behavior in my own code, and not finding any success. I am sorry if I seem outright stupid, but this is all really confusing me. Here is what my structure looks like; My repository is private, so I cannot really just link to it.
app_content
scripts
home
controls
models
editors
utils
UserControls.ts
UserMapping.ts
UserElements.ts
ui
lib
jquery
jquery.js
jquery.validate.js
jquery.ui.js
kendo
kendo.all.js
kendo.aspnetmvc.js
// other libraries
Alright, that's a general feel for my folder layout. All typescript files are under the /home folder so that I can prevent github from saving their compiled javascript and locking that.
So then, in the file UserControls.ts, it looks like this right now...
import userElements = require('./UserElements');
import userMapping = require('./UserMapping');
export class UserControls {
// code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
import userElements = require('utils/UserElements');
import userMapping = require('utils/UserMapping');
export class UserControls {
// some code
}
No matter what combinations I have tried, this is the only format/syntax that doesn't throw errors in Visual Studio. But from what I see in the RavenDB project, I should very much be able to declare it like ...
That is because they are using a drandalJS configuration to tell it how to resolve the file path. (see https://github.com/ayende/ravendb/blob/New3/Raven.Studio.Html5/App/main.js)
There isn't a similar configuration (basePath) for TypeScript at the moment. Your best option is to use relative paths as you've already noticed.
PS: an old but still relevant video that shows you how requirejs config works and relevance when using TypeScript https://www.youtube.com/watch?v=4AGQpv0MKsA&hd=1
The TypeScript compiler's module resolution algorithm is essentially undocumented, unfortunately. It tries to "split the difference" between AMD and CommonJS's module resolution rules, so it's somewhat hard to reason about.
What you're seeing here is an attempt to mimic CommonJS's "walk up the tree" resolution rule. When in the path C:\a\b\c\d resolving x, first C:\a\b\c\d\x is tried, then C:\a\b\c\x, then C:\a\b\x, and so on until it hits the root folder and gives up.
I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.