requiring ///<reference...> is redundant and unnecessary

Topics: General
Aug 20, 2013 at 12:41 AM
The need to use ///<reference...> markup is a drag. It requires typing out a long, awkward path for something the compiler should be fully and entirely capable of figuring out on its own, especially when compiling for Node.

Having to type out:
///<reference path="some/ridiculous/standardized/DefinitelyTyped/path/foo.d.ts"/>
import foo = require('foo');
instead of just:
import foo = require('foo');
is really redundant. Let's not get started on how this syntax isn't inline with the (IMO better) ES6 syntax proposals. :)
  1. know the path that Node (or AMD) uses for module lookup and look for a .ts implementing that module directly, possibly by taking an extra --include-path option to the compiler to specify paths to search
  2. do the same as above but look for a .d.ts file if the imported module is a .js so that code which is shipped as a .js with an accompanying .d.ts just works with no extra trickery
  3. have a path for where .d.ts files laid out similarly to DefinitelyTyped's layout is searched for module names for modules found via the regular paths, e.g. a --definitions-path option or the like
The Visual Studio plugin also needs integration of all this, e.g. debugging support for starting up Node and setting the proper reference paths.

Right now, Typescript is somewhat painful to use for Node development, with or without Visual Studio. Minor syntactical improvements don't count for much when the tooling integration support is still so lacking.
Aug 20, 2013 at 8:55 AM
@SeanMiddleditch,

This issue has been debated extensively in the forum.

https://typescript.codeplex.com/discussions/448336
https://typescript.codeplex.com/discussions/433456

However, the TypeScript team are still dragging their feet over this - which is disappointing. Their first priority of fixing the language features is understandable, but there has been no word on what they want to do about this.

I'm personally not in favour of passing in paths via a compiler option. That does seem like rather an ad hoc solution, because, in Visual Studio, that would involve editing the project XML every time a path needs to change.
Aug 20, 2013 at 6:45 PM
Thanks, I didn't find those previous discussions.

I don't think that having paths in the command line will be an issue in Visual Studio. An IDE's entire purpose is to be smarter than a plain text editor and figure out most of that project-specific stuff. It should automatically know that if I'm building a Node project to use "--module CommonJS --include-path $(PROJECT_DIR)\node_modules --definitions-path $(PROJECT_DIR)\node_modules --definitions-path $(PROJECT_DIR)\DefinitelyTyped". Or whatever is appropriate for the myriad other TypeScript-based project types that should be supported.

While VS is at it, it should also have a NuGet-like interface to npm, tsd, component.io, and so on. Syntax highlighting and code completion are really nice but project and build management are also critical to an IDE actually being useful, and TypeScript support in VisualStudio falls flat on its face in that regard right now, especially for server-side development.
Aug 21, 2013 at 3:32 PM
Agree that an IDE should be smarter - if possible.

Incidentally, it appears that with the release of 0.9.1, the compiler has (belatedly) got a bit smarter. I believe it now makes a pass through all the .ts files in a project, building up its type repository prior to commencing on the compilation.

The implications are twofold:
:
  1. It's no longer necessary to reference types within the same project, because the compiler is aware of them.
  2. References to types outside the project need to be defined only once.
By dint of the latter it's now possible to simply add a "_references.ts" file to the project containing the troublesome paths:
///<reference path="some/ridiculous/standardized/DefinitelyTyped/path/foo.d.ts"/>
///<reference path="some/other/ridiculous/standardized/DefinitelyTyped/path/foo.d.ts"/>
This is certainly an improvement to the status quo - I only hope it's a new feature and not an inadvertent bug!

IMO the icing on this particular cake would be if a using foo.bar; were introduced so that developers may decide which modules are imported into a specific code file. This would make the code more readable, by making explicit the referenced modules in a file.
Aug 22, 2013 at 1:14 AM
nabog: This seems completely Visual Studio specific though, tsc on the command line doesn't behave this way. Naturally it can't know what files belong to the project and which don't there. Since this behavior is Visual Studio only at this point I find it kinda useless currently...
Developer
Aug 22, 2013 at 2:02 AM
@nabog that behavior is intentional, it was one of the breaking changes in 0.9.1 https://typescript.codeplex.com/wikipage?title=Known%20breaking%20changes%20between%200.8%20and%200.9&referringTitle=Documentation

In Visual Studio, all TypeScript files in a project are considered to be referencing each other
Description: Previously, all TypeScript files in a project had to reference each other explicitly. With 0.9.1, they now implicitly reference all other TypeScript files in the project. For existing projects that fit multiple projects into a single projects, these will now have to be separate projects.

Reason: This greatly simplifies using TypeScript in the project context.
Aug 22, 2013 at 6:31 PM
Edited Aug 22, 2013 at 6:32 PM
@danquirk,

this was a pretty good change for us. The TypeScript project setup in Visual Studio is looking much more streamlined: We've been able to reduce the <reference> includes from some 400 plus lines to just 20-odd, which makes things more manageable when it comes to refactoring paths or determining linkages between projects.

So thanks!

One fly in the ointment is that types in declarations files included in a project are not being picked up automatically, unlike those in .ts files. We often declare interfaces directly in declarations files because that makes the F12 editing more straightforward (otherwise F12 takes one to a generated .d.ts file).

In another matter, there appears to be a need to include files referenced by the project being referenced in a third project, for example:

Project1: foo.ts
Project2: bar.ts depends on foo.d.ts; the reference is added to a project-level "_references.ts" file. Project 2 compiles fine.
Project3: Depends on bar.d.ts For the project to compile it's also necessary to add a reference to "foo.d.ts". Ideally this should not be necessary.



@hachre, commiserations!