Specify (absolute) path for library projects

I'm moving this issue here from codeplex:
https://typescript.codeplex.com/workitem/1414

This feature would help to use "library projects" in a way that you only have to specify the actual path once (eg. with a compiler flag).

I'd love to see this implemented in the official compiler. I think it's small work and adds huge value.
I can have a try at adding this but I'd value some guidelines on how to edit the compiler and how it would make it's way to be part of the official compiler.

Seems reasonable. If someone has a precise proposal (https://github.com/Microsoft/TypeScript/wiki/Writing-Good-Design-Proposals) that would be great.

Without being too formal (yet) I think the compiler flagged version could work (as proposed in the codeplex issue).
Maybe it would be more convenient to be able to specify a config json file, similarly to requirejs, something like this:

tsc ... --var pathConfig=config.json

config.json contains the absolute paths of the libraries

{
"projectA": "/libs/projectA/src",
"projectB": "/libs/projectB/trunk/src"
}

+1 the current compiler does not provide enough configuration.
Have a look at gulp and grunt tsc wrappers, there are several and they are quite big. This is an indication that current tsc needs more thought.

I'm thinking if a config.json will be used, should we have it as an individual file just for the path config or would there be other uses for a common config.json that could be fed to the compiler. In which case it would have a content similar to this:

{
"path": {
   "projectA": "/libs/projectA/src",
   "projectB": "/libs/projectB/src"
},
otherConfigOption: {...}
}

Regarding implementation and usage, I think it'd be pretty straightforward, just substitute the project's path so this:

/// <reference path="{projectA}/Foo.ts" />

becomes this:

/// <reference path="/libs/projectA/src/Foo.ts" />

It only makes sense to use {projectA} as the first characters of the path string although it wouldn't hurt to allow to place it anywhere.

What do you think?

To me this is the only missing peace from TypeScript to be able use it in production. So please do comment on the above! :)

This is a big one for me. There absolutely must be a way to import references relative to your project's root.

There absolutely must be a way to import references relative to your project's root

As a current workaround you can use grunt-ts transforms : https://github.com/grunt-ts/grunt-ts#transforms

Actually there's absolute path available for references but it's relative to the root of the hard drive which I think is quite unuseful - couldn't it be changed to be relative to the project's root folder ie. the folder you run the compiler in. Eg. if you compile your files like this:

Main.ts --out $ProjectFileDir$/build/app.js (projectfiledir is a webstorm variable)

then project root is the folder Main.ts is located in.

Nevertheless, even if it did work like this I think there would be a need to use {projectA} like substitutions, because that can work like a symbolic link to a library project.
If you just used the path of the project instead and that path changed you'd have to change it everywhere you use that library project from.

Is there anything I can do to help this move forward?

Is there a reason why the same lookup strategy as the 'require' statement can't be used? A fully qualified path from the root would then work as expected.

Wow.
It's been over a year since I proposed this solution and it is still not implemented (https://typescript.codeplex.com/discussions/451757).
It is too difficult to develop?

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) sent me an answer regarding my questions. This includes tips for implementing if anyone would like to - I didn't have the time to get into it yet.

Here's his reply:

Additional things we’d like to see in a proposal like this would be:

Detailed motivating examples, with brief commentary on how the current compiler doesn’t meet your needs
Several example config files, and a description of their schema
If possible, an implementation (in a fork)

Tips on implementing, since I think this should be fairly straightforward:

In types.ts:
- Add a field to CompilerOptions to store the library paths => file paths mappings
In tsc.ts:
- Add code somewhere to read the specified config file (since commandLineParser doesn’t do file I/O itself)
- Modify getSourceFile to apply the path transforms to the provided filename
In commandLineParser.ts:
- Add a new commandline option for specifying the config file

Caveats: Our design backlog is very full right now (lots of ES6 features to figure out), so it will be a while before we have a chance to look at anything lower-level. We also might end up folding this suggestion in to the external module resolution proposal if it makes sense.

If anyone's working on this, see #1567 for a "motivating example".

TL;DR: RequireJS does not play nicely when you try to use relative module paths from various project locations. Currently the only way to get around this is to define every AMD module in a separate definition file, with the aliased AMD paths.

For an AMD project of any real size, this is a maintenance nightmare.

Caveats: Our design backlog is very full right now (lots of ES6 features to figure out), so it will be a while before we have a chance to look at anything lower-level. We also might end up folding this suggestion in to the external module resolution proposal if it makes sense.

I understand the push for more and more features, but I would urge the TypeScript team to take a step back and make sure that existing features are well thought out and documented. I just spent the last week trying to convert a large RequireJS project over to TypeScript. I was disappointed with how many "gotchyas" I ran into when trying to use the TypeScript module system, and how little documentation there was for the problems I experienced.

The reason I suggested a special character (e.g.: @) is that without it, the path is ambiguous. Is it from the root (i.e.: relative to one of the specified paths) , or is it relative to the current file. In Java, it is always from the root (or roots, as defined by the classpath), and so no special character is necessary. But to support both existing relative paths and root-level paths, it would be better to be explicit. This also reduces the amount of searching that would be necessary, and eliminates an accidental hit (however unlikely) where the author meant one, but got another.

FWIW I made a proof of concept of the fact that tooling can make it easier : https://github.com/TypeStrong/atom-typescript#relative-paths it can do even more over time.

We consider this thing to be outside the scope of tsc, which we generally think of a compiler that does what it needs to and nothing extra. External build systems that understand TypeScript can provide this functionality themselves and provide better flexibility and configurability.

If those external tools settle on a good common pattern that everyone likes, or don't come up with anything at all, we can revisit this post-2.0.

Ryan Cavanaugh (@RyanCavanaugh)

We consider this thing to be outside the scope of tsc, which we generally think of a compiler that does what it needs to and nothing extra.

Ryan Cavanaugh (@RyanCavanaugh) - I would really like this to be the case, but the problem is that tsc has already taken on the task of converting ES6 style module imports to AMD style imports. Now that that decision is made, we're kind of stuck with supporting the quirks of AMD module loading, one of which is the lack of support for relative import paths.

I think the best solution would be for TypeScript to split out the *TypeScript to Javascript compiler" from the the "ES6 module to CommonJS/AMD" compiler. Then we could certainly close this issue as out-of-scope. But if that's not he direction the TS team wants to go, I would like to see better support for AMD.

Edan Schwartz (@eschwartz)

Edan Schwartz (@eschwartz) We are looking into solving some of these issues in #2338, we expect this to be in TypeScript 1.6; can you take a look at the suggestion and let us know if that solves the issues you are running into with AMD?

Banging my head against this issue currently. My scenario:

Code lives in a 'source' folder that is a sibling of the 'typings' folder (from tsd). So all of the reference tags use relative paths to step out of 'source' and into 'typings'. This code is then being deployed via bower, which, by default, dumps the files into a 'bower_components' folder. So now the type files (*.d.ts) are within 'bower_components\source' and need one more relative step up to get to the 'typings' folder at the root level.

I'll take a look at the suggested transform suggestions above.

Turns out if I leave out the /// <reference> tags altogether the code still compiles as long as the ambient declaration files are given to the compiler or added to tsd.d.ts

That is by design. See http://blog.icanmakethiswork.io/2015/02/hey-tsconfigjson-where-have-you-been.html?m=1 for more about not needing reference tags

it'd be good to have a ~ like .NET .. then at least we could move around files in the directories themselves whilst not having to worry about breaking relative references

eg
/// <reference path="~/typings/jQuery.d.ts" />

Navigation Menu

Repository navigation

Specify (absolute) path for library projects #293

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Specify (absolute) path for library projects #293

Description

Activity

danquirk commented on Jul 29, 2014

andrewvarga commented on Jul 29, 2014

bestander commented on Jul 29, 2014

andrewvarga commented on Jul 30, 2014

andrewvarga commented on Aug 2, 2014

ifeltsweet commented on Aug 4, 2014

basarat commented on Aug 4, 2014

andrewvarga commented on Aug 4, 2014

andrewvarga commented on Aug 9, 2014

ecp3 commented on Aug 29, 2014

paztis commented on Oct 15, 2014

andrewvarga commented on Oct 15, 2014

eschwartz commented on Dec 30, 2014

6 remaining items

mconner commented on Apr 6, 2015

basarat commented on Apr 7, 2015

RyanCavanaugh commented on Apr 27, 2015

eschwartz commented on Apr 29, 2015

mhegazy commented on Apr 29, 2015

SonofNun15 commented on Jun 3, 2015

SonofNun15 commented on Jun 4, 2015

basarat commented on Jun 4, 2015

jmp909 commented on Sep 22, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions