breaking-change: move ts-node from dependency to peer dependency

[felipeplets]

As ts-node is a dependency of ts-mocha it does not allow to use of newer versions of ts-node with it making dedupe and hoisting techniques hard to be applied.

[piotrwitek]

@felipeplets I was thinking about it but not everyone needs to install ts-node in their project, also it'll break existing user's projects, they will need to install manually ts-node to their projects with the appropriate version depending on their config and feature set, if they just install the most recent it will break their config right off the bat as v7 is not compatible with a newer version of ts-node.
Furthermore, it will break when a new version of ts-node is published that contain breaking changes thus adding a maintenance burden on the project.
Are any other alternative approaches that will make your use case work without breaking existing users' use cases?

[piotrwitek]

I know the general idea behind this change but I would like to understand a real-world example of why this change is necessary now and why it was never reported by anyone before. The biggest concern I'm worried about is I don't want to introduce unneeded changes to the users if it was working fine so far.

[felipeplets]

it will break their config right off the bat as v7 is not compatible with a newer version of ts-node.
I tried it with different versions from v7 to v10 and couldn't find any issues between those versions. Do you know what specifically would break?

The problem I am facing is that we are reducing (deduping and hosting) dependencies installed in a large project. Big part is reducing dev tools like typescript, ts-node, mocha, etc... some dependencies have hard dependencies like ts-mocha which make it impossible to not have ts-node v7 installed.

Most other dev tools solve the problem of compatibility by using peerDependencies which we already do. So basically we are saying with the peerDependencies that ts-mocha works with any version from v7 to v10 of ts-node (I tested and it seems true) but we actually force the installation of v7. So we are taking away the control from the library user to define any ts-node in that range.

Let's say ts-node v11 is released, the package manager will warn the user they are breaking that based on peerDependencies, but they can still do at their own risk. If it break we can point users to the requirements and the warning educating them about that.