hmil / rest.ts

Type safety across REST APIs in TypeScript!
MIT License
105 stars 6 forks source link

Update peer dependency from rest-ts-express to rest-ts-core #2

Closed erikhofer closed 5 years ago

erikhofer commented 5 years ago

https://github.com/hmil/rest.ts/blob/2740846238e23db1269f6a5453d5ea4300c561b6/packages/rest-ts-express/package.json#L19

It still works but npm shows a warning:

npm WARN rest-ts-express@0.0.7 requires a peer of rest-ts-core@^0.0.2 but none was installed.

Can lerna do this automatically?

erikhofer commented 5 years ago

Same for axios: https://github.com/hmil/rest.ts/blob/2740846238e23db1269f6a5453d5ea4300c561b6/packages/rest-ts-axios/package.json#L19

erikhofer commented 5 years ago

This seems to be intended: https://github.com/lerna/lerna/issues/1575 Maybe use normal dependency instead of peer?

hmil commented 5 years ago

Yes, I think I will do that.

hmil commented 5 years ago

Thanks for binging this up!

hmil commented 5 years ago

It's the first time I'm using lerna and I have to say I'm pretty disappointed. I've used Makefiles so far and I think I'll just go back to that because lerna is not helping at all, it's just adding useless overhead.

Now, for the problem in this issue. I will keep the dependency as a "peerDependency" with the caret range because it suits the use case of this module quite well. Then the release script should take care to update the actual version in the peerDependencies block.

erikhofer commented 5 years ago

I think lerna is great for managing dependencies between different packages in a monorepo. Do you think it's worth it to implement the functionality of lerna manually, e.g. the creation of symlinks for dependencies?

Also what is the reasoning for using peerDependencies across different parts of the same project?

hmil commented 5 years ago

In this repo I'm not sharing code across the projects, so it doesn't really matter if I have a symlink or not. A simple "baseURL": ".." in tsconfig.json would do the trick with much less complexity.

Besides, even for projects that share code, I've use a different system based on a combination of baseURL and NODE_PATH which I describe in details here: https://blog.hmil.fr/2018/05/TypeScript-project-structure2/ .

Maybe lerna reduces the boilerplate and makes publishing easier, but at the same time it requires prior knowledge of the tool. Like here, if I want to know how to update the cross-dependencies of my project, it'll require hours of googling. I'm better off rolling my own system and this way I can tweak it at ease.

Also what is the reasoning for using peerDependencies across different parts of the same project?

By using peerDependencies I let the consumer of my library chose which exact version they want to roll. Usually they'll set everything to the same version, but imagine there's a feature they need in rest-ts-axios@2.1.1 but there is a bug in rest-ts-core@2.1.1. They can easily downgrade to rest-ts-core@2.0.2 and keep rest-ts-axios@2.1.1, if I use peerDependencies with caret range. With hard dependencies there is no escape hatch.

hmil commented 5 years ago

Hey @erikhofer ,

I made a bunch of modifications over the week-end, including a lot of bug fixes. I also changed the way you create the express router to use a builder instead of a plain object hash. It's supposed to help provide better auto-completion than the previous solution.

If you are still using this library, please check out the latest version and let me know what you think!