ts-pnp should be a peer/optional dependency.

[jpickwell]

To avoid getting an unmet peer dependency "typescript@*" warning, ts-pnp should be a peer or optional dependency. Your only use of ts-pnp is in an exported function that isn't used by your code. I don't see why your code should have anything typescript specific in it. If it's needed by external code, then make your interface more generic, and let that external code do whatever it needs to to hook in to your code.

[arcanis]

Unfortunately if ts-pnp was a peer dependency the same problem would happen (except that the warning would be unmet peer dependency "ts-pnp@*"). If it was an optional dependency, the warning would also always be there (optional dependencies only downgrade hard failures). The TS helper is very small and could be implemented in a separate package, but I wanted pnp-webpack-plugin to be as ready-to-use as possible.

Starting from Yarn 1.14 (scheduled for release in a few days) we'll add support for optional peer dependencies, which will hopefully solve this issue - I'll just declare typescript as an optional peer dependency of pnp-webpack-plugin, which will silence the warning 🙂

[wedi]

optionalDependencies are here! 🎉

Is it just a matter of adding it to package.json? I havent' created a pull request (yet) as I don't know which version selector to use.

    "optionalDependencies": {
        "typescript": "^3.4.5"
    }

[arcanis]

Optional *peer dependency 🙂

It should already be good - typescript is declared as an optional peer dependency of ts-pnp (cf here), so that should fix the problem.