0

I've looked around a lot in the last few days ... and I was never able to succeed with this

What I'm trying to achieve: I am developing in a (forked) existing react library and I want to "link" the test project using this library to the development folder of the library, so that every change of the library code will be available inside the test project without the need to build the library first.

This (to me) sounds like something everyone is doing every day. Nevertheless, I'm not able to get it working on my side.

The library has its own dependencies (obviously)

What I did: I tried to use this to link the test project to the library

cd my-test-project
npm link ../my-react-library

Is this a correct step? What else do I need to do in order to be able to use a component from this library in my test project?

EDIT: Ok, I can see the link with npm ls, so I guess it is the right way to start. But what next?

>> npm ls -g --depth=0 --link=true
C:\Users\xxxxxx\AppData\Roaming\npm
├── my-react-library@4.10.0 -> .\D:\Project Folders\ReactProjects\my-react-library
└── react@17.0.2 -> .\D:\Project Folders\ReactProjects\...............\node_modules\react
devnull69
  • 16,402
  • 8
  • 50
  • 61
  • 1
    Does the `package.json` of `my-react-library` point to the built version in the `main` or `module` fields? If so, you probably also need to change `import` statements to reach into the module and import individual files from source instead. However, this is a pain. Usually you'd solve this issue differently, by just having a separate build watch process in `my-react-library` and let the changes propagate. With your link solution that should work fine. – adsy Jul 27 '23 at 19:27
  • 1
    Essentially, if you choose to import from source, you are basically making the build of the third party lib your problem, which arguably breaks module encapsulation and is kind of asking for issues. Hence the suggestion to link and have the third party build in a background watch process. That keeps the separation as it should be and is more representative of a production setup. – adsy Jul 27 '23 at 19:28
  • I begin to grasp that my idea of a project setup might not be the best approach. Can you maybe point me to a more reasonable development setup description for the case that the test project is separate from the library project, because I cannot change the structure of the library project? The goal is to be able to debug both the test project and the library project together in the browser – devnull69 Jul 27 '23 at 19:46
  • 1
    So here the purpose of linking it is mostly to just add temporary debug code or something? The above still applies but is probably overkill. Honestly for that kind of thing I usually just hack the built code in `node_modules` as its easier (no link, just npm install). If that's impractical for some reason, what you were doing (link it) makes sense. But you'd also need to run the build of the third party library. Check the third party libraries `script` entries in `package.json` as there may be `watch` option which makes it less painful. But yeh...hacking in `node_modules` gets you quite far. – adsy Jul 27 '23 at 20:09
  • 1
    I think I may not be fully grasping your needs but if its instead active development of a fork alongside your consumer app long term, Id definitely consider using NPM workspaces (or pnpm workspaces or yarn workspaces, depending on what package manager you use). That allows everything to work together from source with share deps as if its all one project. In this solution you'd integrate it with the parent build system so you've got one wholistic project. – adsy Jul 27 '23 at 20:12

0 Answers0