Bump vite

[antoinell]

This pull request is the same as bump-mermaid without bumping mermaid.
Feel free to squash all the commits in the pull request when merging.
There are 2 systematic changes in the pull request in the reactjs code :

• components extend explicitly React.Component instead of just Component
• import statements when applied to types have the type keyword added to them
  The first change was necessary to get the tsc compiler to succeed
  The second change was necessary so that vite remains able to display the demonstration application in znai-reactjs with npm run dev

[MykolaGolubyev]

where did you move indexCreation.js?

[antoinell]

It is replaced by another file called initialization.js in another package.

[MykolaGolubyev]

is this file required for Vite migration?

[antoinell]

The new eslint consumes this file

[MykolaGolubyev]

this tmp path looks suspicious

[antoinell]

it is common practice, it comes from the template https://github.com/vitejs/vite/blob/main/packages/create-vite/template-react-ts/tsconfig.app.json . So if you create a new plain vanilla vite react application using https://blog.logrocket.com/how-to-build-react-typescript-app-vite/ you will get this.

[MykolaGolubyev]

do you remember what is this for?

[antoinell]

This file replaces indexCreation.js. It gets at the other end of the HTML.

[MykolaGolubyev]

I mean why do we need Mutation Observer?

[antoinell]

In previous iterations, there were javascript runtime errors happening in relationship with populating the search index data. I thought that the search index data might have arrived in an asynchronous fashion and I got one of the AIs I consulted to generate this code. I am removing the Mutation Observer as all the tests pass without it.

[MykolaGolubyev]

do you know why need to ignore this?

[antoinell]

There is a red inspection warning in IntelliJ and this is what made me add this line. I just asked Claude about this issue and here is what is suggested

Based on the search results, IntelliJ is showing a red inspection alert on the CSS import because TypeScript doesn't know how to handle CSS file imports by default. The proper solution is to add type declarations for CSS imports.

Why the Error Occurs

When working with Vite and TypeScript, you need to add type definitions for asset imports like CSS files. Vite provides default types through vite/client, but TypeScript still needs to be told that importing .css files is valid.

The Proper Solution

You need to create a type declaration file (.d.ts) that tells TypeScript that CSS imports are valid. Here's what to do:

1. Create or update vite-env.d.ts in your src directory:

/// <reference types="vite/client" />

// Add declaration for CSS imports
declare module "*.css" {
  const content: Record<string, string>;
  export default content;
}

2. Alternatively, if you're using CSS Modules specifically:

/// <reference types="vite/client" />

declare module "*.module.css" {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module "*.css" {
  const css: string;
  export default css;
}

3. Ensure this file is included in your tsconfig.json:

{
  "compilerOptions": {
    "types": ["vite/client"]
  },
  "include": ["src/**/*", "vite-env.d.ts"]
}

Why This Works

Vite's default types are for its Node.js API. To handle client-side code in a Vite application, you need to add a d.ts declaration file with a reference to vite/client. The type declaration tells TypeScript that importing CSS files is valid and what type they return.

After adding this file, IntelliJ should no longer show the red inspection alert on your CSS imports.

[antoinell]

Let me remove the // @ts-ignore annotation for now, and we could make another P/R to deal properly with all the inspection errors found by IntelliJ.
Also we should make a change so that when the keyword type is absent where it should be present together with export a compilation error happens.

[MykolaGolubyev]

Yeah I am not a fan of the new errors. There are dozens of files that just include css file and don't need types as they never refer to the css classes inside via typescript

[MykolaGolubyev]

why is this added?

[antoinell]

An inspection in IntelliJ says

TS1294: This syntax is not allowed when erasableSyntaxOnly is enabled.

let me remove the // @ts-ignore as it is not a proper solution.
Here is what Claude says about how to fix the issue :

Perfect! Now I understand the issue. The error is caused by the erasableSyntaxOnly TypeScript compiler flag that's likely been enabled in your updated tsconfig.json as part of the Vite bump.

What's Happening

The erasableSyntaxOnly flag marks enums, namespaces and class parameter properties as errors because these pieces of syntax are not considered erasable - they generate JavaScript code at runtime.

Parameter properties in class constructors like constructor(private name: string) get transformed into actual JavaScript code that assigns properties, rather than being simply erased like type annotations.

The Proper Solution

You need to expand the parameter property shorthand into explicit property declarations and assignments:

Change from:

class DocElement {
  constructor(readonly content: DocElementContent) {}
}

To:

class DocElement {
  readonly content: DocElementContent;
  
  constructor(content: DocElementContent) {
    this.content = content;
  }
}

Why This Is Required

Your PR likely updated to a newer TypeScript configuration (possibly from @tsconfig/vite-react or similar) that enables erasableSyntaxOnly: true. This flag is enabled by default in the latest @tsconfig/vite-react package.

This flag enforces that your code only uses "erasable" TypeScript features - those that can be stripped away without changing the JavaScript behavior, which aligns with modern runtime TypeScript support in Node.js and other environments.

Alternative: Disable the Flag

If you don't want to refactor all your code, you can disable this flag in your tsconfig.json:

{
  "compilerOptions": {
    "erasableSyntaxOnly": false
  }
}

However, the recommended approach is to refactor to the expanded syntax, as it's more compatible with modern TypeScript tooling and runtime type stripping.

[antoinell]

About the change Component --> React.Component

Based on the search results, the reason for changing from Component to React.Component in .jsx files is related to how Vite handles JSX in .js files and the need for explicit React imports when using certain configurations.

The Core Issue

When using Vite, files with JSX syntax need to be in .jsx files. Vite parses .js files as plain JavaScript, not JSX. If JSX appears in .js files without proper configuration, Vite throws syntax errors.

The PR likely had to deal with one of these scenarios:

Most Likely Reason: JSX Files Without Auto-Import

When using older React patterns or certain Vite configurations, files may not have automatic React imports. The jsxInject option can auto-import React, but if not configured properly, it can cause conflicts when React is already imported.

When the PR removed the JSX pragma comments (like /** @jsx React.createElement */), it also likely removed automatic handling of React being in scope. Without React explicitly imported or in scope, writing Component alone doesn't work because:

// This fails without React in scope:
class MyComponent extends Component { }

// This works:
class MyComponent extends React.Component { }

Why This Is Necessary With Vite

The @vitejs/plugin-react plugin by default uses the automatic JSX runtime. However, you can opt out using the jsxRuntime option to use classic mode, which requires React to be in scope.

If your PR switched between JSX runtime modes or changed how React is imported, the code needs to explicitly reference React.Component rather than relying on Component being destructured from an import.

The Solution

The change from:

import { Component } from 'react';
class Svg extends Component { }

To:

import React from 'react';
class Svg extends React.Component { }

Makes the code more robust and compatible with different JSX configurations, especially when:

• Using classic JSX runtime
• Files have .jsx extension and Vite needs clear React references
• Avoiding issues with HMR (Hot Module Replacement) that expects React to be in scope

This is a safer pattern that works across more configurations without relying on destructured imports.