Specify (absolute) path for library projects

[andrewvarga]

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.

[danquirk]

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

[andrewvarga]

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"
}

[bestander]

+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.

[andrewvarga]

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?

[andrewvarga]

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

[ifeltsweet]

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

[basarat]

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

[andrewvarga]

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.

[andrewvarga]

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

[ecp3]

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.

[paztis]

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?

[andrewvarga]

@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.