GeezerVison

Bill Ticehurst (@billti) You should probably take a quick look at this.
Ron Buckton (@rbuckton) I've used your suggestion for this area of code from my other PR, so you should probably take a look, too.

This seems like a lot more code change than we need. I was thinking just something like the below in program.ts @ 781 would be sufficient, which is a minor change to existing logic. Anywhere this has issues?

            if (baseName !== "node_modules") {
                // Try to load source from the package 
                const packageResult = loadModuleFromNodeModulesFolder(moduleName, directory, failedLookupLocations, state);
                if (packageResult && hasTypeScriptFileExtension(packageResult)) {
                    // Always prefer TypeScript source (.ts, .tsx, .d.ts) shipped with the package
                    return packageResult;
                }
                else {
                    // Else prefer a types package over non-TypeScript results (e.g. JavaScript files)
                    const typesResult = loadModuleFromNodeModulesFolder(combinePaths("@types", moduleName), directory, failedLookupLocations, state);
                    if (typesResult || packageResult) {
                        return typesResult || packageResult;
                    }
                }
            }

I just tested the above simple change and that seems to work fine too. I'll push some commits to the (slightly) related change at #9421 for review.

Bill Ticehurst (@billti) I have ulterior motives for making this a little more complicated: I need to make it easy (in the near future) to specify that I want to load js files only for resolving modules in the extension PR (which is where the first draft of this code came from).

Additionally, we were passing a handful of flags around to control the loading of js and jsx/tsx - this now unifies them. And, thanks to a little bit more effort, is now merged with the ExtensionPriority enum used by globbing.

Right, I was figuring as much. But we need this fix for 2.0, which has already snapped for stabilization. I'd rather keep it as simple as possible, especially as the extensibility stuff is very early on at this point and may go through more changes. That said, I'll let Mohamed Hegazy (@mhegazy) make the call on which pull request to take.

On a related note, Travis finally finished testing this PR and it's now lit up green. :D

I do agree with Bill Ticehurst (@billti) for 2.0 i think #9421 is sufficient. we ca take these other changes separately, and no need to lump them here.

Mohamed Hegazy (@mhegazy) Now that we've cut a 2.0 beta and have a PR out to bump the version tag in master to 2.1, can we look into merging this refactoring again?

Vladimir Matveev (@vladima) Could you look at this PR?

This is stale by now. sorry for the delay. closing.