Have typescript as a peerDependency

[myitcv]

@vvakame - can we move TypeScript to be a peerDependency?

  "dependencies": {
    "commandpost": "1.0.0",
    "editorconfig": "0.13.2",
    "es6-promise": "3.0.2",
    "glob-expand": "0.1.0"
  },
  "peerDependencies": {
    "typescript": "^1.7.3"
  },
  "devDependencies": {
    "espower-loader": "1.0.0",
    "grunt": "0.4.5",
    "grunt-contrib-clean": "0.7.0",
    "grunt-conventional-changelog": "5.0.0",
    "grunt-dtsm": "0.2.9",
    "grunt-exec": "0.4.6",
    "grunt-mocha-test": "0.12.7",
    "grunt-ts": "5.2.0",
    "grunt-tsconfig-update": "0.0.1",
    "grunt-tslint": "3.0.0",
    "load-grunt-tasks": "3.3.0",
    "mocha": "2.3.4",
    "power-assert": "1.2.0",
    "tslint": "3.1.1"
  }

We just got bitten the following situation:

• Using v1.1.0, one of our team had typescript-formatter referencing v1.6.2 of TypeScript; I had it depending on v1.7.3 (not by design, simply a fluke)
• There were formatting differences between these two versions of TypeScript that meant our output formatting the same file was different (which we have configured to cause our CI build to fail)

If TypeScript were a peerDependency then this situation wouldn't arise, because it would pick up the version we have in our package.json which is 1.8.0-dev.20151201... and it would mean we can pick up the latest formatting 'fixes' in typescript@next

We have also moved back to using npm-shrinkwrap.json given this is fixed in the latest npm which should help avoid these sorts of situations

Thoughts?

[demurgos]

Personally, I feel that the recent trend of peerDependecies defeats the purpose of npm by bringing back dependency management to the user. I think that the best solution would be to keep typescript as a regular dependency, but also allow the user to optionally provide a reference to its own typescript object when using the Node API.
It would require to keep the reference to ts when passing options to functions but this way it does not enforce the user to install some specific version at some specific location.

See gulp-tsc if you want an example: the typescript dependency acts as a default and the user can provide its own version.

[vvakame]

sorry for late reply.

https://docs.npmjs.com/files/package.json

NOTE: npm versions 1 and 2 will automatically install peerDependencies if they are not explicitly depended upon higher in the dependency tree. In the next major version of npm (npm@3), this will no longer be the case. You will receive a warning that the peerDependency is not installed instead.

and http://blog.npmjs.org/post/110924823920/npm-weekly-5

I don't use peerDependency in tsfmt.

https://docs.npmjs.com/misc/semver

Prerelease tags can't match to ^1.7.5.
I don't want to use * in tsfmt. it can match to [email protected]. It can have a API breaking change.

We need way to satisfy prerelease tag issue and npm install -g typescript-formatter on [email protected] both.
I don't have the answer now. 😣

@demurgos I think gulp-tsc has same issue about this repo.

$ npm init
$ npm install --save-dev typescript@next gulp-tsc
$ cat node_modules/gulp-tsc/node_modules/typescript/package.json | grep version
  "version": "1.7.5" // not 1.8.0-dev.20160124!

[vvakame]

dirty (and terrible) hack... $ rm -rf node_modules/typescript-formatter/node_modules/typescript.

[myitcv]

@demurgos just read the search algorithm for tsc/TypeScript; it sound eminently sensible.

I suppose the only point of contention (which might be where peerDependencies came about) is that you end up having multiple versions of TypeScript installed if you follow this pattern, which doesn't make any sense in the context of a given project. Whilst disk space is cheap, I think the concept of peerDependencies actually simplifies things from a package management perspective. The search algorithm I linked to can still function exactly as described, with the exception that step 3 would no longer be valid under a peerDependencies model.

[demurgos]

@demurgos I think gulp-tsc has same issue about this repo.

$ npm init
$ npm install --save-dev typescript@next gulp-tsc
$ cat node_modules/gulp-tsc/node_modules/typescript/package.json | grep version
"version": "1.7.5" // not 1.8.0-dev.20160124!

@vvakame
Obviously, the version inside gulp-tsc is the one specified in their package.json. My point is that it only serves as a fallback if no other version is provided/found (See the link in the comment above).

@myitcv
My take on disk-space usage VS dependency-hell is that node and npm were right on what's important: having "local" resolution to prevent interference between modules is really valuable.
It's been 7 years that npm installs plugins with local duplication and nobody really complained. With npm@3 they managed to greatly reduce redundancies: that's great but module redundancy should be npm's concern, not module authors'. I would also prefer to have only one version of each module but even if it works at one point in time, it's a pain to maintain as modules are updated, and that's what peerDependencies are all about...

With peerDependencies, you MUST manually install the core dependency (typescript) and the plugin dependency (typescript-formatter) at the same level. With multiple plugins eventually in relying on multiple versions, it can even lead to conflicts.

I just experienced this problem with gulp-tslint: it has a peerDependency on tslint which has itself a peerDependency on typescript@>=1.7.3. I'm using typescript@next (1.8.0-dev.20160125) which is not matched because it's a pre-release so it triggers warnings.

Finally, I would also argue that even when using peerDependencies, it would be neat to provide a way for the user to supply it's own reference for typescript (with the API, using options, arguments, etc.). I'm writing a small module for common tasks used across my projects (ie: formatting) and I want to use the typescript version from the current project. Ideally, the project calls the build module with a references to the used typescript and then the build modules pass it to some plugin. (And of course, the build module has it's own default version). When using peerDependencies, the plugin tries to grab the nearest version itself and circumvent any way to pass an other version.

Here is a discussion about plugins that might be relevant. (Even if in this case, this plugin cannot work without typescript).

Ultimately, this is a great module and you seem really experienced so you will come up with a good solution, but I still wanted to express my reserve about peerDependencies. Keep up the good work 😉

[myitcv]

This just reared its head again microsoft/TypeScript#6856

@vvakame - that terrible hack is indeed terrible!

Prerelease tags can't match to ^1.7.5.
I don't want to use * in tsfmt. it can match to [email protected]. It can have a API breaking change.

tslint does the following:

...
  "peerDependencies": {
    "typescript": ">=1.7.3 || >=1.8.0-dev || >=1.9.0-dev"
  },
...

Can we not adopt the same approach for tsfmt?

[vvakame]

@myitcv I decided to follow the tslint... 😉 please try 2.0.0

[myitcv]

@vvakame - thanks very much, working like a dream now!