Move typescript to dev dependencies
#28
Conversation
Fixes issue ezolenko#27.
|
Thanks! I'd rather add an option to override used typescript instead, with whatever user requires manually themselves. (I won't be able to work on it for some time though) This pr will break builds for some people. There was a similar issue in the original plugin, they settled on having ts as direct dependency iirc. Could you elaborate what's your use case, maybe there is a better way? |
|
We're using your plugin in a big project, and simply haven't yet gotten around to updating our code for typescript 2.4. I believe this issue would be a deal breaker for many, or would fragment the rollup-typescript plugin space even more by encouraging forks. |
|
I see. I was going to suggest trying moving it to peerDependencies, but then I saw it is already there... And it is also depreciated in npm3... (https://codingwithspike.wordpress.com/2016/01/21/dealing-with-the-deprecation-of-peerdependencies-in-npm-3/) If you are using npm3, could you try relaxing dependency rule for typescript to |
|
Imagine the following scenario:
This plugin does have a runtime dependency on Typescript since the Language Service is used by the plugin. Hence, making it a development dependency will not only be a breaking change for many, but also make usage of automated builds via Travis/CircleCI/etc impossible without adding a hard dependency on Typescript which not all users may be aware of. I agree with @ezolenko that we should make it possible to pass in another version of Typescript as an argument. Typescript v>=2.4.2 would then still be installed but not conflict with the version your team is using. It would solve the problem without breaking changes and reduce possible errors and confusion for new users |
|
Custom typescript option is in master now. If that works as expected we can close this PR. |
Fixes issue #27.