[#371] relax tsutils peer dependency

[sapegin]

To prevent warning when using newer tsutils version:

warning "[email protected]" has incorrect peer dependency "[email protected]".

[msftclas]

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

[Delagen]

@msftclas I still think that this must be full dependency.
NPM 2 or NPM from 3 to 5 with legacy-bundling will be broken if tsutils missing in package.json of main project (only tslint and tslint-microsoft-contrib)

[HamletDRC]

@Delagen I don't think I should make it a full dependency. tslint-microsoft-contrib is just a folder that tslint calls into. It does not have any actual dependencies, it only inherits dependencies from tslint. Even if I added a full dependency, I don't think it would be used. tslint would load itself and the tsutils modules, and then load one of our rule files from disk.

What I can do is delete the peer dependency entirely. This is a transitive dependency satisfied by tslint, and we need to just rely on whatever tslint gives us.

@sapegin if I just delete the tslint peer dependency then will this still work for you?

[sapegin]

I actually agree with @Delagen — for me it’s like Lodash or any other utility library, I’d put it into dependencies myself, just use ^ to use the same version that ESLint may use.

[HamletDRC]

@sapegin @Delagen
I had a misunderstanding of what tsutils is.

I think it should be a full dependency.

Can you point your project at our #releases branch and see if this fixes the issue for you?

[HamletDRC]

@sapegin does thumbs up mean you tested it? Nothing was ever failing for me, so all my tests pass regardless.

[sapegin]

@HamletDRC Works fine for me!

[westy92]

It looks like this was reverted when switching from a peerDependency to a dependency.
d33dbf6
Does anybody know why?

[HamletDRC]

@westy92 As per the discussion above, we are looking to move this from a peerDependency to a dependency.

Is there a reason why it needs to be a peerDependency and a dependency?

I assumed the commit you reference is the correct way to do it.

cc @sapegin @Delagen

[westy92]

It should be a dependency and not a peerDependency.
This PR changed it from a strict version to >=1.6.0, but when it was moved from a peerDependency to a dependency, the >= was changed to ^. I believe it should be fixed to again use >= to re-fix what this PR accomplished, "prevent warning when using newer tsutils version."

[sapegin]

It will warn only when using a new major version.

[westy92]

I understand, it just seems like a step backwards to go from >=1.6.0 (no warning) to ^1.4.0 (warning).

[sapegin]

Actually having >= is not that safe and useful — it may just break without an npm warning if a new major release isn’t backwards compatible ;-)

[sapegin]

And according to their 2.0.0 change log that is very likely. So I think we should use ^2.0.0 here.

[HamletDRC]

Triggering a release now... expect something in npm by end of day.

[reduckted]

So I think we should use ^2.0.0 here.

I agree. Is there any reason why it's still using 1.6.0?