#2411 [Investigation] Move to Vite from Rollup for project build

[yuleicul]

Closes #2411

Proposed Solutions to Speeding Up Development Experience

Proposed solutions

Vite for development, Rollup for build.

For development, to create a new dev workspace by Vite, e.g. /dev. Its functionality equals to current /example, but engined by Vite which will make the development faster.

For build, keep current Rollup configurations and the build workflow the same.

New development workflow

In root

npm install

In /dev

# For standalone
npm run start:standalone

# For remote
npm run start:remote

NB! When you finish coding, before creating a PR, you'd better preview your implementation to make sure everything works fine with Rollup. Please follow DEVNOTES -> Development to preview.

Why

Why not replace Rollup with Vite?

It'll take more effort and may cause other problems, but the optimization is a little or even none.

Ketcher uses Rollup to build libraries. If we replace Rollup with Vite, that means we use Vite to build libraries. As for build, Rollup is not worse than Vite which uses Rollup under the hood. On top of that, Vite is also blamed for non-consistency between development and production environment.

I've taken two days to replace Rollup with Vite in ketcher-core and ketcher-react, but as I thought, optimizations are a little or even none.

The following data is based on my Windows 10, with 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz 2.61 GHz.

For ketcher-core, the build time changes from 11.5s to 13.49s

For ketcher-react, the build time changes from 23.9s to 20.42s

Why Vite for development?

Easy to answer, because Vite is fast for development. Vite leverages native ES Modules in the browser to load your code instantly, no matter how large the App is. Instead of importing a single JavaScript bundle file, it's importing our actual source code, like a raw .tsx file. It also makes TypeScript about 20–30 times faster because it skips type checking and uses esBuild to transpile your code. Vite also supports Hot Module Replacement for an extremely fast feedback loop during development.

Compared to approximately more than 10 seconds to wait after changes when developing, Vite just takes 1 second.

before-vite.mp4

after-vite.mp4

Next steps

It depends on what we're gonna achieve in the end.

If we're gonna replace /example totally (although I don't recommend doing it), at this moment I don't have an estimate. We need to implement all the commands in /example, and now I only finished two of them. The main difficulty might be the build command because we need to replace Webpack which is used in /example  with Vite.

If we're just gonna make Vite the dev tool (this is also what I recommend), then the majority of work is already done for it during the investigation. Things that may need to be improved have been listed below. Notice that, in this way, everything we do in /example should be done the same in /dev. Considering we hardly ever change code in /example, I guess it would be not a big deal.

If you ask why I recommend the latter way, it's because /example is something we can show to our users how to use Ketcher with Webpack.

[yuleicul]

Improve me

Alias

In dev/vite.config.ts, all alias are defined here. The question is, if there are same named alias in different packages, Vite may not find the correct package. For example, if we have domain which maps src/domain in ketcher-core, at the same time we have domain which maps src/domain in ketcher-react, then the dev/vite.config.ts looks like

resolve: {
  alias: [
    { find: 'domain', replacement: '../packages/ketcher-core/src/domain' },
    { find: 'domain', replacement: '../packages/ketcher-react/src/domain'}
  ]
}

In this case, Vite may not replace domain correctly. I have no idea how to resolve this problem at this moment. See more about resolve.alias.

Environment variables

In dev/vite.config.ts, all env variables are defined here. However, Vite can't handle same named env variables in different packages. For example, we have process.env.VERSION: JSON.stringify(pkg.version) in ketcher-react, and we have the same env variable in ketcher-polymer-editor-react. In this case, we can only define one of them. To fix this, we have to rename one of them.

TypeScript Config

At this moment, if we export a new type from ketcher-core, other packages like ketcher-react will not detect it. I guess it can be fixed by modifying ts.config files.