React+Vite boilerplate

[jmuzina]

Creates a boilerplate with Vite that can be used to generating React applications using our design system.

Fixes WD-16920

QA

1. Checkout this PR
2. Run bun i
3. CD into apps/boilerplate-react-vite
4. bun run dev
5. Open the boilerplate

Screenshot

[jmuzina]

Here's a "boilerplate of the boilerplate", so to speak 😄

Generated with bun create vite and adding in dependencies to our shared configs.

When setting this up and running checks on it, I wrestled with some tsc errors. Dependencies on React 19 types from @types/react and @types/react-dom that were introduced by this boilerplate bled into other packages. I fixed this by adding the DOM lib to the ts_example package.

[jmuzina]

Next up: finish & test this boilerplate

Later: update this boilerplate to use our code generator, once that is implemented

[jmuzina]

@advl I'm getting an interesting error on install (which runs build via prepare) now.

 error during build:
      [commonjs--resolver] Failed to resolve entry for package "@canonical/ds". The package may have incorrect main/module/exports specified in its package.json.
          at packageEntryFailure (file:///Users/jmuzina/source/repos/vanilla-monorepo/node_modules/vite/dist/node/chunks/dep-Cyk9bIUq.js:46626:15)

the boilerplate uses @canonical/ds as a dependency and imports a button from it.

Interestingly, the error doesn't happen if i run bun install a second time.

So, steps for recreation:

1. Clear build artifacts: rm -rf node_modules packages/ds/dist apps/boilerplate-react-vite/dist
2. Install: bun install --frozen-lockfile
3. Observe error
4. Run install again
5. Observe no error

Have you ever run into something like this before when working with a monorepo?

[advl]

On the react types : these should be removed as they are already provided by react 17 and above?

[jmuzina]

@advl

I have fixed the build error: it was a race condition due to using --parallel in the lerna build command. I took oiut --parallel for the build script, so now lerna uses package.json dependencies to determine build order.

Regarding react types: these have been added as peer dependencies so that the CI passes. Otherwise, tsc fails (as seen here).

I found information on the React 19 guide that seems to suggest installation of the types is still necessary; see here

CI is now passing and there is an executable node script for initializing a boilerplate, so I'm happy with this. I'll write some QA instructions shortly and move this to ready for review.

[advl]

Minor questions related to configs.

[jmuzina]

@advl Updated per our discussions today:

React Core UI - Storybook type checking fixes

The errors arose from me trying to remove skipLibCheck from the react core package for increased strictness. There are two ways to resolve this in the short term:

1. Type-check storybook files (.stories and .stories.ts(x)) with "module": "ESNext", "moduleResolution": "Bundler"
2. Enable skipLibCheck for storybook files (.stories and .stories.ts(x))

I have used option # 2, skipLibCheck per our earlier discussion when you mentioned we should try and avoid changing module settings. This is already the behavior of the library on main, the change I made here is setting skipLibCheck to false in the library build (which excludes storybook files).

Boilerplate Tsconfig

The boilerplate's typescript configuration has been brought more into line with the other packages - it now has a tsconfig.json that checks all typescript files (intended for type-checking), and a configuration for building the application (that excludes the vite config file).

The building config file has been named tsconfig.app.json, as users are probably building their applications with vite build rather than tsc in this context. vite.config.ts has been configured to build with tsconfig.app.json using the vite-tsconfig-paths plugin.

Open question

It feels a bit strange to add a dependency just so that we can build with a tsconfig other than tsconfig.json.

We either have to break with our current convention of tsconfig.json being used just for type-checking with tsc --noEmit (which would allow us to remove this dependency), or use this dependency to continue with that convention.

Have a look when you can, please.

[jmuzina]

Last task: cleanup the tsconfig.app.json in the boilerplate, try and use just one config @jmuzina