Hi @carlosdubus, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@carlosdubus, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, MSBOT;

Hi @carlosdubus, you added resolve as a devDependency, I think it should be a normal dependency in this case as it required runtime and not only for development

Have a look at angular/clang-format@2f9ceb9
where @mprobst added similar support to clang-format.

//cc: @billti

Playing with this a bit, I am not sure we would want to take this change. with node v5 now flattening modules is the default, so if you are in a folder, and transitively, one of your imports has a dependency on TypeScript, it will be in ./node_modules/typescript and that can be confusing. at least now it is consistent.

What about using the content of package.json (either parsing it or getting
from some npm command) to determine if typescript is an explicit dependency
of the project?

Note the value here is if someone on the team updates TypeScript, then some
time later, other people on the team get broken by the first new language
feature added. Days of "hey does someone remember how to fix the build
setup" ensue.

On Fri, Oct 30, 2015 at 4:00 PM Mohamed Hegazy notifications@github.com
wrote:

Closed #5465 #5465.

—
Reply to this email directly or view it on GitHub
#5465 (comment).

@alexeagle I definitely see the value of it, but is that a common thing that other node projects do as well?

gulp warns if you have a different version installed locally than global
one you're running.
clang-format has been very beneficial with this feature, before that the
team was very frequently running an out-of-date globally installed version.
It would be interesting to scan other packages on npm to see if they have
this behavior...

On Sun, Nov 1, 2015 at 12:53 AM Daniel Rosenwasser notifications@github.com
wrote:

@alexeagle https://github.com/alexeagle I definitely see the value of
it, but is that a common thing that other node projects do as well?

—
Reply to this email directly or view it on GitHub
#5465 (comment)
.

Another challenge is that on Windows running tsc will often run our tsc.exe SDK compiler, which uses Chakra and not Node, so we can't have a solution (at least not a cross platform, consistent one) that depends on loading Node / NPM modules.

Would an option be to use an NPM script ( https://docs.npmjs.com/cli/run-script )? This always looks in the ./node_modules/.bin directory first, so if a specific version of TypeScript is installed as a dependency, it will run that version.

For example, if your package.json scripts command had an entry:

"scripts": {
        "tsc": "tsc"
    }

Then running npm run tsc would run the dependent version installed, not the global version.

You can also pass args to it (e.g. run npm run tsc -- --version to verify the right version is being run), or just have the script automatically build and watch the project (e.g. the scripts entry could be: "tscw": "tsc -w -p ./", then just running npm run tscw would automatically build and watch the tsconfig.json in the root folder, using the TypeScript compiler installed as a dependency).

I'm actually a big fan of warning the user that they are using a different version than is installed locally. I'll open an issue for that.

In fact, npm run tsc is exactly the recipe we currently suggest in our
docs, eg.
https://angular.io/docs/ts/latest/quickstart.html

On Mon, Nov 2, 2015 at 3:40 PM Daniel Rosenwasser notifications@github.com
wrote:

I'm actually a big fan of warning the user that they are using a different
version than is installed locally. I'll open an issue for that.

—
Reply to this email directly or view it on GitHub
#5465 (comment)
.