TypeScript should be a peerdependency

[arcanis]

Expected Behaviour

ts-loader shouldn't rely on undefined behaviors

Actual Behaviour

ts-loader currently relies on the hoisting in order to have access to the typescript package

The fix is pretty simple: typescript just has to be listed as a peerDependencies of ts-loader (rather than just a devDependencies). This will guarantee that it will then get the exact same instance than its parent. It can be listed as both if you want to also install it by default on dev environments.

Steps to Reproduce the Problem

It causes issues with package trees that do not support hoisting, such as Yarn Plug'n'Play.

Location of a Minimal Repository that Demonstrates the Issue.

Because Plug'n'Play has a fallback mechanism, hitting this case is a bit more difficult to reproduce - but basically, if you have a workspace that depends on both ts-loader and typescript, it won't work (because ts-loader won't be allowed to access typescript as it's not one of its dependencies, and because the fallback won't kick in since typescript will be in a workspace rather than the top-level module).

[johnnyreilly]

I'm open to this but I'm not sure how feasible it is. We build ts-loader with a specific version of TypeScript (latest and greatest usually) so we have a high version devDependency. But typically TypeScript can be used with a whole number of different versions of TypeScript. I'm not sure we can have it listed as a peer dependency as well as a devDependency with different versions.

BTW yarn is fine; I can say that as that's what I use!

[arcanis]

I'm not sure we can have it listed as a peer dependency as well as a devDependency with different versions.

It shouldn't be an issue semantically speaking - devDependencies are only installed for the top-level package, which by definition cannot see their peer dependencies satisfied. Something like this should give you the behavior you wish:

{
  "devDependencies": {
    "typescript": "latest"
  },
  "peerDependencies": {
    "typescript": "*"
  }
}

BTW yarn is fine; I can say that as that's what I use!

Glad to hear that! I'm actually one of Yarn's maintainers 😄

We've recently unveiled the Plug'n'Play project, which will (optionally for now) enforce strict boundaries between packages (à la pnpm) and will allow the installs to become much faster and safer. It might cause some issues when packages don't list their whole set of dependency, hence my report 🙂

[johnnyreilly]

Would you like to submit a PR that adds peerDependencies / devDependencies as suggested above?

I'll take it for a whirl. If it works without problems then I'd be happy to merge it 😄

[marvinhagemeister]

We're using the same strategy for some private packages at work. It's perfectly fine to specify something in both devDependencies and peerDependencies 👍

[arcanis]

#841 adds the dependency to the peerDependencies field! 🙂