Remove preferGlobal flag

[JeroMiya]

Most projects should be using a local version of the typescript compiler, typically via a build tool like grunt/gulp, not a globally installed one. That way each project can upgrade the typescript compiler when it's ready to. The warning on npm install is misleading, and can confuse new programmers jumping into an existing project.

[danquirk]

Seems worth considering. I think originally we imagined taking so few breaking changes that you'd just always use the latest tsc since a project that hadn't updated to vNext features would still 'just work' with the new compiler. Since we've been taking more breaking changes over time it's less and less the case that you could confidently take all your new projects to tsc vNext and experience 0 new errors. In which case you'd be more likely to use the workflow described here with a local tsc rather than a global one.

[dead-claudia]

Not saying I disagree with this (I don't), but TypeScript isn't the only one guilty of using "preferGlobal": true, when the best, most common use case is locally. Even CoffeeScriptRedux, Traceur, and (almost surprisingly) Browserify don't. It's simple enough, I'm opening a quick PR for it.

_{(The ones I linked were CoffeeScript, Babel's CLI, LiveScript, and JSHint.)}

[RyanCavanaugh]

Not sure. From the NPM docs:

If your package is primarily a command-line application that should be installed globally, then set this value to true to provide a warning if it is installed locally

I think this applies to the NPM typescript package (same as it does to the other packages you linked). I don't believe that local usage is the most common use case -- is there any data available on that?

... can confuse new programmers jumping into an existing project.

I agree with this part, but come to a different conclusion. The way I see it is that there are two cases -- people who generally know what they're doing with NPM packages, and people who don't.

The people who know what they're doing understand how to do version management and will know to ignore the warning about preferGlobal because they want a local version. Removing this setting doesn't help them.

The people who don't know what they're doing run npm install typescript, see that running tsc doesn't work, then look at the warning that says "install with -g please", run npm install -g typescript, and avoid thinking that TypeScript or NPM are broken. Removing this setting hurts these people a lot, and is going to create noise for us because people will say "I ran npm install typescript and it didn't install tsc !" and we'll have to tell them about a flag that we could have warned them about automatically.

Is my logic off here?

[dead-claudia]

@RyanCavanaugh

Browserify does not. And out searching for "npm" and "command", the only one I found that is remotely close to that kind of problem is this bug. And I actually clicked on about a quarter of them (the ones that weren't immediately obvious as not related). As for a heuristic off of that, people are usually stupid, but developers are usually not as stupid as the general public. They aren't as stupid as the large number of people who ask me if I know how to hack some system, even if they know I'm a web developer, or those that assume I can program, thus I know how to fix every hardware/software issue on the planet. Developers, in my experience, are not usually the ones to say "this program doesn't work - this company is !" over a small bug.

I don't know a lot of end-user, general public programs that require them to use npm to install it. Most people, at the sight of monospaced code, tend to get a little uncertain about what's going on, and Windows users are the worst.

Also, sadly, on a near-weekly basis I'm asked about some Windows issue by a family member, even though they know I use Ubuntu.

[JeroMiya]

First, keep in mind that removing the flag doesn't mean users can't still install typescript globally. It just removes the warning which, for a significant portion of users, is not really true - the preferred place to install the compiler is at the project level, not global. Remember, projects want to list typescript as a dependency not just because of breaking changes, but because they need a minimum version.

I doubt using tsc from the command line is a common usage of the compiler, or any compiler for that matter. For new users, it's easier to just open up a .ts file in an IDE or editor that supports compile-on-save and just hit save, which defaults to compiling it into the same directory. For experienced users, they will either do the same or use a build system like grunt/gulp. With TypeScript 1.5's tsconfig.json functionality, it's even less likely any users, new or experienced, will be using tsc from the command line, by hand. It's just not practical, for nearly any use case. I mean, can you imagine any project, open source or closed, requiring users to compile files individually, by hand, from the command line? It's just not done.

Besides, the best pattern in npm for command line utilities that are primarily versioned at the project level is to have a separate *-cli npm package that is installed globally. See for example grunt and grunt-cli. Alternatively, the single typescript package, when installed globally, would look for a locally installed version and run that instead, before falling back to itself. Even if you go the second route, you would still remove the preferGlobal flag, because both local and global are acceptable choices.

[dead-claudia]

@JeroMiya A few (Gulp as an example) just bundle both the module and CLI into a module, and requires the local version for the task list, bailing if one doesn't exist.

[JeroMiya]

@IMPinball yes, I pointed out that option as well. in that case, I would still remove the flag because the package serves a dual use (local or global), where the global package would defer to the local one, if present.

[weswigham]

As @JeroMiya brings up, that the TS package has multiple reasons to install it is part of the issue - stemming from the multiple ways to use npm install - you can install executables (ie, -g) and/or update/install dependencies with it. And those dependencies may be for another node package or for a browserify/webpack/component/whatever browser project. As has been mentioned by others, given how the community that uses npm works, the dependency management cases might be more likely than the cli installation case.

The typescript npm package provides many services - some of which should be preferGlobaled, some of which should not. typescript as in tsc should be preferGlobal - it provides what is intended to be a global executable installation, and should be globally available. typescript as in tsserver should probably not be global - applications which depend on it (despite it being executable) would likely prefer to bundle a specific version of it (and generally do so already). typescript as in 'the library and platform' should probably not be global - again, tools which depend on it as a library would likely like to bundle a specific version. There's also a few other distributions in bin - typescriptServices (which is the same sources as typescript but not for node) and tslssl (which is just tsserver as a library). On top of those, there are the standard library .d.ts files which all of them rely on.

All of these are distributed on npm via one monolithic package at present. Given that their only dependencies are on one another at build time (sans common dependency on standard library .d.ts files), it doesn't seem impossible to publish each deliverable to separate packages to alleviate the issue. There really are a handful of distinct services provided by this repository.