Question on Dev Workflow - npm link?

[curran]

I notice that the examples under packages/dev import things from the Unovis NPM package, for example:

import { VisSingleContainer, VisDonut } from '@unovis/react'

My question is, how do Unovis developers test their changes? Is everyone using npm link to link the NPM packages to the local source files?

It may be cleaner to leverage NPM workspaces for this, so npm link would not be required.

[rokotyan]

Can you please describe the problem you're trying to solve? The dev app links the package directly from the source (see the webpack config)

[curran]

Yes! Here is a description of the problem, phrased as a user story:

As a developer new to Unovis, I want to be able to use the VSCode Go To Definition feature, so that I can easily navigate the codebase during development.

Current behavior: this feature doesn't work, because only Webpack knows how to resolve the imports. If symlinks were used, as in NPM workspaces or npm link, the Go To Definition feature would work.

Initially seeing the imports, I did not assume Webpack was configured in any special way, and that the code changes would not propagate, because Go To Definition took me into node_modules. So the problem is not actually in testing local changes, but rather in developer experience related to VSCode.

What I Experienced

The problem is a developer experience issue where when you try to follow the imports to their definition in VSCode, like this,

it resolves to node_modules, and then you need to go searching the codebase for the file that matches.

Following it to the definition in VSCode lands you in a .d.ts file, which is essentially a dead end. You can't easily find the source file where a given export is defined in.

For example, I wanted to inspect the source code that defines <VisSingleContainer /> so that I could understand what happens to the props, specifically the height prop. In order to actually fine the implementation, I need to do a codebase-wide search like this:

Then I'm left staring down the results list and clicking through multiple ones to try to figure out if it's the thing that was imported. The only ones that actually match in those search results are these, which are for Vue and Svelte, not React.

I spent way too long scrolling up and down that list, only to navigate from the src tree and see if I could find it that way. Eventually I did find it, defined in packages/react/src/containers/single-container/index.tsx.

Suggested Improvement

Let's somehow get the symlinks to work, so that when you follow a definition in VSCode, it takes you straight to the definition, not to a dead-end .d.ts file. NPM Workspaces does this by default. So does npm link.

I do see this config here in packages/dev/webpack.config.js, but that only applies to the build toolchain. It does not create symlinks that VSCode can follow.

I feel like this is worth doing, if only just for my own sanity stepping into this codebase. I will see if npm link even works. It could be a rabbit hole...

Thanks for asking for clarification!

[curran]

There are some other VSCode features that are also broken, since it can't resolve the imports.

[rokotyan]

There are some other VSCode features that are also broken, since it can't resolve the imports.

I don't see this problem on my end. Do you have it everywhere in dev or only with specific files?

NPM Workspaces does this by default.

Where was some problem with having dev as a workspace. But I don't remember what exactly though. Feel free to try adding it back there and see what happens

[curran]

Oh interesting... I wonder if there's some additional VSCode extensions that make it work that I need to install.

I see these issues everywhere in the dev package.

[curran]

Impacts module resolution errors in VSCode as well.

In this case the thing actually is exported and the code that imports it runs fine.

Somehow, the @unovis/ts does resolve to the source tree, but it resolve to lib, which seems to have generated files.

Interestingly, the @unovis/react import resolves to node_modules. I wonder why this is different than @unovis/ts...

[rokotyan]

@curran Since it points to the built version of @unovis/ts, VSCode won't be able to find the export unless you build the library.

We can probably solve that by using TypeScript Project References or by using path aliases, but it'll require some experimentation.