allow baseUrl, paths, rootDirs in tsconfig files

[laurelnaiad]

Re: #833, Add the above as valid tsconfig.json properties.

Note: this change does not necessarily make these properties functional, it
simply allows them to be passed to the transpiler.

baseUrl and paths seem to work. rootDirs has not been verified and
might not be functioning (at least on cur. typescript@next).

TODO: this does not yet deeply validate the paths and rootDirs properties.

I plan to mark this as closing the issue if I can figure out what's up with rootDirs as time permits, but this might be merge-able now as a starting point.

[mko]

+1

[basarat]

@laurelnaiad I've added you as an owner. Please do whatever you want with this package. Merge then publish https://github.com/TypeStrong/atom-typescript/blob/master/CONTRIBUTING.md#publishing then write notes at https://github.com/TypeStrong/atom-typescript/releases 🌹

Feel free to @ mention me if you need any help.

[laurelnaiad]

@basarat !? :(

Yikes. I'll do what I can.... does this mean that you're really backing off on atom-typescript? I can't carry your load.... more hands, sharper tacks needed..... I will have questions for you when I have some breathing room from project work.

[basarat]

I can't carry your load

Don't worry you are just one of the many people. Just means that I trust your code explicitly and don't feel the need to review it 🌹

does this mean that you're really backing off on atom-typescript?

I'm trying to limit my OSS work, sticking to StackOverflow + alm.tools + typescript book. Focus for this year is revising Algorithms and Data Structures 🌹

[laurelnaiad]

Ok... I'll look at the rootDirs situation tomorrow and see if I can finish this off with the accoutrements that an owner would provide.... :)

[laurelnaiad]

I'm developing a theory that this PR leaves behind an issue relating to LanguageServiceHost(2) losing track of files. I'm wondering whether it's receiving partial paths where it clearly wants absolute ones.

All I know for sure so far is that my instances of "The file '/Users/dmaddox/.../somewhere/suchAndSuch.ts' is not included in the Typescript compilation context. If this is not intended..." have gone way up. Hopefully I'll have some time soon to dig into this.

[mko]

I locally had implemented this same concept slightly differently than in your PR, and I saw the same problem. If I have time on Monday, I'll try to dig into resolving those issues with you.

Michael Owens
mk@mowens.com
https://mowens.com
@mko

On Feb 26, 2016, at 10:55 AM, Daphne Maddox notifications@github.com wrote:

I'm developing a theory that this PR leaves behind an issue relating to LanguageServiceHost(2) losing track of files. I'm wondering whether it's receiving partial paths where it clearly wants absolute ones.

All I know for sure so far is that my instances of "The file '/Users/dmaddox/.../somewhere/suchAndSuch.ts' is not included in the Typescript compilation context. If this is not intended..." have gone way up. Hopefully I'll have some time soon to dig into this.

—
Reply to this email directly or view it on GitHub.

[laurelnaiad]

Strong circumstantial evidence that non-rooted paths are sneaking their way into places they shouldn't be:

This is an exerpt from having done the following logging in the source:

app/routes/layout/layout.ts
app/routes/root/root.ts
/Users/dmaddox/Documents/_ws/myproj/src/browser/app/ng1Providers.ts
/Users/dmaddox/Documents/_ws/myproj/src/browser/node_modules/rxjs/add/observable/zip.d.ts
/Users/dmaddox/Documents/_ws/myproj/src/browser/app/app.ts
/Users/dmaddox/Documents/_ws/myproj/src/browser/app/appState.d.ts

from project.ts

    /** all files except lib.d.ts  */
    public getProjectSourceFiles(): ts.SourceFile[] {
        var libFile = languageServiceHost.getDefaultLibFilePath(this.projectFile.project.compilerOptions);
        var files
            = this.languageService.getProgram().getSourceFiles().filter(
              x => {

                console.error(x.fileName) // laurelnaiad's addition
                return x.fileName !== libFile
              }
        );
        return files;
    }

Those non-rooted paths just happen to be some of the ones that are being reported as "not in a compilation context".

[laurelnaiad]

I find it slightly odd, I guess, that in the presence of tsconfig files that have files arrays, that we'd be asking tsc for a list of files in the project... but I guess there are reasons. In any case, I guess the fix is to resolve to rooted-paths... wherever that lands is probably also a reasonable place/time to address rootDirs, I suppose.

[tomitrescak]

👍 Can't wait for this one! ;)

[laurelnaiad]

Me, too! :) I tried hacking at the getProjectSourceFiles function to see if teaching it how to resolve the paths would help, but apparently that function is also used in place where finding the files leads to confusion in tsc itself (assertion errors that we're looking for a file that doesn't exist)... so apparently I messed with the wrong function...

I am going to try to carve out a little time this weekend to find an alternative function to hack. :)

[basarat]

No need to provide defaults if they are not activated (basically let the TS compiler do its own default thing). Also explicit undefined initialization not needed (it undefined on read anyways) 🌹

[basarat]

I just added the support to http://alm.tools : alm-tools/alm#73 🌹

The only thing missing from this PR I think is that baseUrl isn't being make absolute as soon as its read from the the tsconfig.json file (see other examples like outFile in the same code here https://github.com/TypeStrong/atom-typescript/blob/de5aca96840dfc8723652f115d17341bf217320d/lib/main/tsconfig/tsconfig.ts).

[basarat]

rootDirs would just work too if the path resolution is done up front. See alm-tools/alm#74 for commit 🌹

[talski]

Hello guys, any news when this will come out?

[PatrickJS]

+1

[basarat]

Superceeded by (now merged) #996 🌹