Core: Vite integration

[50rayn]

In this PR done a couple of things:

• upgrade existing Vite modules to 6
• in @unovis/ts package was replaced rollup with Vite

During integration, I met some misunderstandings, like:

Why in .npmrc do we have legacy-peer-deps=true?

Because of this flag, I could not install the latest version of vite-plugin-dts.

In @unovis/ts in tsconfig, do we have a lot of paths configured? Why?

It makes more ambiguous the imports in the files. You may not understand it's imported from a file, module, and alias. I'd add just one, "@/*": ["src/*"]. It's more common for most users.

I wanted to be sure that I could open some PRs for each of the mentions, but first of all, I need to be sure if it makes sense.

[rokotyan]

@50rayn Another great contribution, thanks!

The build looks good, but this dependencies should not be bundled:

Why in .npmrc do we have legacy-peer-deps=true?

To be honest, I don't remember. You can try removing it and see what happens.

In @unovis/ts in tsconfig, do we have a lot of paths configured? Why?

I agree with you. At the beginning of the project it was convenient this way but now it's not. We can change it to a single "@/*" alias.

[50rayn]

Regarding both questions, I can do separate PRs. There, I'll check all the necessary changes.

About those dependencies, it is fixed by ignoring the node_modules from bundleing.

[rokotyan]

@50rayn Thanks! We're planning to release Unovis 1.5 soon. Will get back to this right after

[lee00678]

Hi @50rayn, Thanks for the contribution!

There seems to be an issue with dynamic import moving from rollup to vite. I released a beta version [1.5.1-ql.2](https://www.npmjs.com/package/@unovis/ts/v/1.5.1-ql.2) from this branch and tested it in an angular project. Some of the following path (https://github.com/f5/unovis/blob/main/packages/ts/src/components/leaflet-flow-map/renderer.ts#L1-L9) didn't get resolved correctly.

[rokotyan]

Confirmed. There's a problem with imports that end with the .js extension, for example:
import { Color } from 'three/src/math/Color.js'. Once compiled they have the full local file system path:

import { Color as r } from "/Users/nikitarokotyan/unovis/node_modules/three/src/math/Color.js";

Update: Even if you remove the .js extension from the imports, the problem persist. So it's more related to how the commonjs modules are treated, but to the import syntax itself.

[50rayn]

Thanks, @rokotyan and @lee00678, for the feedback.
I'll take a look.

[rokotyan]

@50rayn I've tried to reconfigure the common js plugin a couple of times but without success. So now I'm out of ideas.

[50rayn]

Hello everyone.
Glad to be back. I took a look at the issue. It was pretty challenging to find the issue with paths, and it was fixed (I hope so 😄). The only thing I could not play with was angular. The gallery script gives me errors (even in prod):

An unhandled exception occurred: Cannot find module 'webpack'

[lee00678]

Hello everyone. Glad to be back. I took a look at the issue. It was pretty challenging to find the issue with paths, and it was fixed (I hope so 😄). The only thing I could not play with was angular. The gallery script gives me errors (even in prod):

An unhandled exception occurred: Cannot find module 'webpack'

Thanks for the update. I will test it this week.

[lee00678]

Hello everyone. Glad to be back. I took a look at the issue. It was pretty challenging to find the issue with paths, and it was fixed (I hope so 😄). The only thing I could not play with was angular. The gallery script gives me errors (even in prod):

An unhandled exception occurred: Cannot find module 'webpack'

Thanks for the update. I will test it this week.

@50rayn have you tried to do npm run dev? I'm getting errors after running a build.

And if you look at the pipeline: https://github.com/f5/unovis/actions/runs/13773780019/job/38734324725?pr=495
Seems like it also fails on the same issue.

[rokotyan]

I don't think we should do this — we want the dev app to import Unovis from the source otherwise we'll have to continuously build the package during development

[50rayn]

Well, I didn't know that this was an issue. I looked at some monorepos like histoire or vue-devtools. If they are going to make some changes in core, let's say ts, they turn on watch mode for both packages. if no, they just build the ts, and run in watch the dev. This way, it can also be tested on the types and how everything is imported/exported. Also, each package should act more independently. Afterwards, I see no sense in monorepo structure. BTW, such an approach can block the integration of PNPM.

[rokotyan]

I see quite a lot of value in having HMR while developing new components. Why do you think it may block PNPM integration?

[50rayn]

The prior Webpack alias pointed to the src/ folder of @unovis/ts which was beneficial for HMR. That said, this can lead to problems with PNPM because of its symlink and dependency management. Resolving @unovis/ts through package.json guarantees symlink support within PNPM and better dependency resolution. In next commits I completely separated the packages from eachother from linking directly and let them be linked through packages.

[rokotyan]

Thanks. I'm a bit concerned about these massive changes, and before we merge them, we'll need to thoroughly test how they would affect the dev workflow. Most likely I won't have any bandwidth for this within the next few months, maybe @lee00678 will.

[50rayn]

Sure thing. It would be perfect if somebody else tested it, just in case I missed something.
The next steps will be:

• PNPM support
• Create a common vite.config (mergeConfig)
• Integrate unit-testing (vitest monorepo)

[lee00678]

I will try to review this in the next 2 weeks.