You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 19, 2019. It is now read-only.
Given that some people like riding the edge with TypeScript (e.g. depending on the latest stable or beta version), but others don't always keep up that much (like in some larger projects), it would be nice if, instead, this had TypeScript as a peer dependency instead. Also, the compiler API itself has been pretty consistent across versions, I believe (or it wouldn't be as common to depend on TypeScript this way).
This is typical across the TypeScript tooling, as TSLint, Atom TypeScript, tsify, gulp-typescript, and many others depend on TypeScript in a similar manner. Most of these packages use "typescript": "*" in their package.json.
Another bonus is that this is how most of the tooling could support JSX the moment it was first implemented, but gracefully fall back if the compiler didn't support it.
The text was updated successfully, but these errors were encountered:
I'll be honest, peer dependencies always make me cringe now that npm forces users to manually install. However, if you're saying that this expected in the TypeScript tooling universe, I can live with it.
@nzakas With respect to the TypeScript compiler itself, it generally is either that, like TSLint or ts-node, or accepting a custom TypeScript compiler as an option (which is more common), like Atom TypeScript, gulp-typescript, or tsify. Some do both (which is the case for both TSLint and ts-node). The reason why several accept a module reference is because of ntypescript, a sugared version of the TypeScript compiler that always pulls from the latest dev version.
I forgot to elaborate a little better on the options, but most TypeScript tooling is very loosely coupled to the compiler itself, because of the slight fragmentation and the fact many users have to take a while to migrate to the next version. There's also ts2dart developed mostly for Angular 2 (which is a whole different platform). It isn't as bad to have to manually install the compiler, though, since you already have to install one in the first place.
Given that some people like riding the edge with TypeScript (e.g. depending on the latest stable or beta version), but others don't always keep up that much (like in some larger projects), it would be nice if, instead, this had TypeScript as a peer dependency instead. Also, the compiler API itself has been pretty consistent across versions, I believe (or it wouldn't be as common to depend on TypeScript this way).
This is typical across the TypeScript tooling, as TSLint, Atom TypeScript, tsify, gulp-typescript, and many others depend on TypeScript in a similar manner. Most of these packages use
"typescript": "*"
in their package.json.Another bonus is that this is how most of the tooling could support JSX the moment it was first implemented, but gracefully fall back if the compiler didn't support it.
The text was updated successfully, but these errors were encountered: