Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
React should be a peer dependencies
See original GitHub issuehttps://github.com/kiegroup/kogito-tooling/blob/master/packages/core-api/package.json#L15-L18
One think I noticed working on the AtlasMap POC is that I was getting the Invalid Hook Call Warning
error in the console. Ultimately, it was due to @kogito/core-api declaring React as direct dependency, which causes for multiple versions of React being embedded in the bundle. Since AtlasMap is written solely using hooks, this issue come up immediately.
A quick workaround was to instruct WebPack to consider React an external dependency, but it would be better to make React and React DOM peer dependencies in the core-api package.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I mean, your project your rules 😄
Let’s say that this would be quite an exception in the npm ecosystem and would limit peers to use the provided template and tools (what if I don’t want to use webpack? Sure things like rollup allow for declaring external global dependencies, but I don’t see why adding this cognitive burden to users).
Yup I think I’m with you. If I may, check out tsdx as a library boilerplate generator. It uses rollup under the hood that’s more suited to create libraries than webpack and makes working with this stuff easier.