core Make JSX typings an optional install as they conflict with React TSX

Make JSX typings an optional install as they conflict with React TSX

Open elevatebart opened this issue 4 years ago • 39 comments

Version

3.0.0-beta.3

Reproduction link

https://github.com/elevatebart/vue-next-react-ts-conflict

Steps to reproduce

# Checkout the repo
git checkout https://github.com/elevatebart/vue-next-react-ts-conflict.git

# Install all modules
npm ci

# run tsc
npm start

The errors you see in the console are due to React and Vue TSX accepting different values.

What is expected?

When migrating from React to Vue, types should not fail without installing them.

What is actually happening?

it fails at compilation

JSX types could be made a separate package: @vue/jsx-types.

This way, types would not systematically be installed.

Devs could install the runtime they need without the typings.

The transition would be easier.

Apr 22 '20 21:04 elevatebart

I could see this problem be solved temporarily by resynchronizing the types of react and vue. I would see this alignment as a nightmare to maintain in the long term.

Apr 22 '20 22:04 elevatebart

But are you going to use JSX/TSX in Vue, or are you going entirely with templates?

While this does make it compile, you still wouldn't be able to use Vue TSX until you completely remove React typings?

Apr 22 '20 22:04 yyx990803

Agreed, and choose when to do this switch from React JSX to Vue JSX.

What do you suggest?

a bit of context

Vue-styleguidist uses React to render a style guide for VueJs components. Most of the code is in react though. Vue only comes in play in the preview. The reason being, same as for storybook, that the original product was written in react.

Should I rewrite it completely using Vue? Though there is a project started for that, I feel like I am letting my users down changing technology suddenly. Since all customizations of styleguidist was done in react before, it would be better to be able to at least choose when they switch.

Really looking forward to your opinion.

Apr 22 '20 22:04 elevatebart

I could create a Pull Request to expose what I think could be useful.

Apr 22 '20 22:04 elevatebart

@shilman, @Aaron-Pool Did you experience the same kind of issue implementing vue-next in storybook?

Apr 23 '20 15:04 elevatebart

The main conflict seems to be about NativeElements/ IntrinsicElements.

Another solution might be to share the definition of the NativeElements in a separate package, then have React and Vue typings depend on the same package.

This way, TSX conflicts will be avoided until one chooses to switch from react TSX to vue TSX.

Apr 23 '20 23:04 elevatebart

@elevatebart we haven't yet implemented vue-next in storybook. you're in uncharted territory! 😄

Apr 23 '20 23:04 shilman

@elevatebart Same here, the furthest I've gone is using jsx with the Vue 2.x composition-api plugin. Haven't started to explore the vue-next waters just yet.

Apr 24 '20 19:04 Aaron-Pool

Hello @DanielRosenwasser,

Does TypeScript have a solution to deal with JSX ambient types conflicting? I tried using the "types":[] trick without luck. I tried using the paths: {} trick to redirect retrieval of types to another object but since types are ambient there is still a conflict.

What solutions do you see?

Apr 26 '20 17:04 elevatebart

Either vue or react not both. That is the same issue by use react and preact together.

Use storybook for your components doc.

May 02 '20 11:05 deleonio

@martinoppitz I do not understand. Do you mean that preact typings are different from react typings?

What do you suggest I do in a monorepo that has both react and Vuejs ?

May 02 '20 14:05 elevatebart

React and VueJs are not in the same package in the above monorepo.

May 02 '20 14:05 elevatebart

I think the ide does not differnce beetween the subfolder projects.

Thank you for this perspective ... because I believe/feel "mono repos are a other name for monoliths."

try to reduce the overhead by managing the independent packages ... a go back to move all in only one repo.

If you are disciplined, then you can also properly design/develop monoliths.

May 02 '20 19:05 deleonio

Thank you @martinoppitz,

I understand your disliking for monorepos. They can create monoliths that are long to clone and even longer to install.

In our case though, the vue-next monorepo could save our bacon. It allows easy extraction of a package in a PR. Once the PR is accepted, all 3 modified packages are delivered at once. No downtime when packages are incompatible or missing a library and e2e testing can continue without breaking.

Regarding JSX, can you expand a little what I should do? Are you implying that this is not an issue? Are you suggesting a maintainer should use one repository for React and one for Vue and they should never mix?

I would not expect The Progressive JavaScript Framework to force a complete rewrite of the code upon adoption if there is another solution.

May 02 '20 20:05 elevatebart

@elevatebart just so you know I'm considering doing this, but still trying to figure out the best way to organize it with the upcoming Vue 3 JSX transform.

May 06 '20 13:05 yyx990803

Thank you @yyx990803, this will help a lot. If you are looking for someone to bounce ideas with, ping me on VueLand. I'll be happy to show enthusiasm or constructive criticism.

Except for this hiccup, the migration to Vue 3 is bringing a lot of performance to docgen and styleguidist. I like it.

May 06 '20 13:05 elevatebart

FYI, namespace JSX can be renamed to avoid conflict (for example, VueJSX ).

And TypeScript uses VueJSX instead of JSX by putting this configuration into tsconfig.json .

"jsxFactory": "VueJSX"

Jul 05 '20 02:07 wonderful-panda

I create a vue project with vue-cli. the project has a dependency of package named B. B has a dependency with react types. for example:

import type { PropsWithChildren } from 'react';

then my project emit errors:

Type '{ children: Element[]; class: string; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'. Property 'class' does not exist on type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'. Did you mean 'className'?ts(2322)

here is my code: index.tsx:

import { defineComponent, ref } from 'vue';
import style from './index.module.less';

export default defineComponent({
  setup() {
    const activeTab = ref('tab-one');
    return () => (
      <div
        class={style.detail}
      >
        xxxx
      </div>
    )
  },
});

I strive for solving this, what can I do with this situation?

remove the package which has a dependency with react library, the error disappear.

by the way. I organized my project with mono repo. which has react project and vue project.

Jun 22 '21 10:06 lcoder

I started getting these errors after installing storybook 3.6.10. My project's stack is vite + vue3 (typescript), while storybook is using webpack and is based on react, so I'm making a wild guess that by adding storybook, these errors started surfacing because of react dependencies.

Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps<OlHTMLAttributes<HTMLOListElement>, HTMLOListElement>'.\n Property 'class' does not exist on type 'DetailedHTMLProps<OlHTMLAttributes<HTMLOListElement>, HTMLOListElement>'. Did you mean 'className'?"

Oct 07 '21 10:10 olemarius

@olemarius did you find more info on this?

Oct 18 '21 08:10 filipecruz

I have a monorepo with one package depending on Vue and other on react. I use pnpm which does not hoists dependencies. Then I have a tsconfig.json for each package. Hence, no JSX conflicts.

But If I have to use Vue and react in same package/file, avoiding conflict is not possible.

Oct 18 '21 15:10 znck

I started getting these errors after installing storybook 3.6.10. My project's stack is vite + vue3 (typescript), while storybook is using webpack and is based on react, so I'm making a wild guess that by adding storybook, these errors started surfacing because of react dependencies.

Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps<OlHTMLAttributes, HTMLOListElement>'.\n Property 'class' does not exist on type 'DetailedHTMLProps<OlHTMLAttributes, HTMLOListElement>'. Did you mean 'className'?"

@olemarius Did you find a way to resolve this I'm having the same problem with Vue and Storybook setup with vite + vue3?

Oct 19 '21 07:10 lauragift21

I had the same problem

Nov 02 '21 07:11 zhang-stone

same problem @yyx990803

Dec 02 '21 12:12 dcy0701

I have the same problem. I get

Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'.
  Property 'class' does not exist on type 'DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>'. Did you mean 'className'?

@olemarius did you resolve it?

Also check: https://github.com/eirslett/storybook-builder-vite and https://storybook.js.org/blog/storybook-for-vite/

Dec 13 '21 12:12 abhic91

Hi,

Try this in your tsconfig.json file

 "exclude": [
        "**/node_modules",
        "**/dist",
        // https://github.com/johnsoncodehk/volar/discussions/592
        "**/*.stories.ts"
    ]

Dec 13 '21 13:12 olemarius

Thanks olemarius.

Adding this fixed it

// tsconfig.json
{
  "compilerOptions": {
    // ...
    "types": [
      "vite/client", // if using vite
      // ...
    ]
  }
}

Dec 14 '21 05:12 abhic91

For me latest @vue/runtime-dom is also conflicting internally. excluding **/*.stories.ts and including vite/client doesn't prevent @vue/runtime-dom having conflict with @types/react. I have no idea where VS Code's TS might grab the React types, but we have @storybook/vue installed and some *.ts storybook stories in the project.