[React] The 16.x.x types are not in npm as @next, so projects are getting them too soon

[kurtinatlanta]

• I tried using the @types/react package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @richseviora

I am grateful to the team that maintains these - please keep up the good work.

The @types definitions for React 16 are getting into the wild too soon causing errors in TypeScript builds.

Even though I have projects that depend on "15.6.0" in order lock-in the version of @types/react, the "*" dependencies in projects like @types/react-dom and @types/react-virtualized seem to allow npm to resolve it all to 16.0.1, which causes builds to break.

React itself is pushing its @16.x.x builds to npm with the @next tag so that builds that want @latest don't inadvertently update to the React 16 betas. The matching @types should do the same.

Here is the resulting error (one for each React.DOM item):
ERROR in [at-loader] ./node_modules/@types/react/index.d.ts:3458:13
TS2403: Subsequent variable declarations must have the same type. Variable 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHTMLAttributes, HTMLAnchorElement>'.

If I hand-edit package-lock.json to make sure that the various dependencies don't resolve to @types/react 16.x.x, the errors go away.

[fix777]

Same issue, please fix this issue ASAP. 😥😥😥

[richseviora]

This is an outcome of PR #18463.

Seems like an issue where npm isn't coalescing the values on your system. I tried to replicate on my system but npm seemed to properly resolve the packages with npm 5.3.0.

@kurtinatlanta Can you take a look and let me know how to replicate the problem you're seeing?

[kurtinatlanta]

@richseviora It's pretty easy to reproduce. I created an empty directory with a fresh package.json (nothing installed) and did this:

$ npm install --save react react-dom
npm notice created a lockfile as package-lock.json. You should commit this file.

+ react-dom@15.6.1
+ react@15.6.1
added 19 packages in 9.564s
$ npm install --save typescript

+ typescript@2.4.2
added 1 package in 1.933s
$ npm install --save @types/react

+ @types/react@16.0.2
added 1 package in 2.686s

As you can see, it gets @types/react 16.0.2, not 15.6.x. This leads me to believe that @latest is getting set in npm to 16.0.2 instead of @next in npm.

Which is proven by this:

$ npm view @types/react
 
{ name: '@types/react',
  description: 'TypeScript definitions for React',
  'dist-tags': 
   { latest: '16.0.2',
     'ts2.0': '15.0.1',
     'ts2.1': '15.0.20',
     'ts2.2': '15.0.30',
     'ts2.3': '16.0.2',
     'ts2.4': '16.0.2',
     'ts2.5': '16.0.2' },
...
}

If I do the same with react itself, I get this:

$ npm view react
 
{ name: 'react',
  description: 'React is a JavaScript library for building user interfaces.',
  'dist-tags': 
   { latest: '15.6.1',
     '0.10.0-rc1': '0.10.0-rc1',
     '0.11.0-rc1': '0.11.0-rc1',
     next: '16.0.0-beta.5',
     dev: '15.5.0-rc.2',
     '0.14-stable': '0.14.9',
     '15-next': '15.6.0-rc.1' },
...
}

Which shows react using the @next tag for 16.0.x.

My conclusion is that @types/react is getting published to npm either without any tag, so npm uses the default @latest, or explicitly with --tag latest in the npm publish command.

[richseviora]

@kurtinatlanta I thought the problem was that you were getting typescript compile errors b/c npm was returning two versions of @types/react because other @types modules had dependencies on @types/react@*, not that you were getting React 16 lifecycle methods before they were useful.

I tried to replicate the former problem, and from a clean build I was not able to reproduce it (see the repository's package-lock.json). Can you help me reproduce that issue? I'm getting the feeling that this might be an npm and/or yarn issue (see #18793).

I don't know that we have the ability to tag types packages as next. I don't see any reference to that in types-publisher. @sheetalkamat, @andy-ms do you know otherwise?

Assuming we don't have the ability tag a specific version as next, I imagine we could make 15.6.0 the root version and place 16.0.0 into a v16 folder. But I'd personally prefer to confirm that the issue is not an npm issue first.

[corydeppen]

From over a year ago...

...we definitely don't want the @latest tag pointing to pre-releases (via microsoft/types-publisher#12)

It seems to only make sense that types packages would be able to specify a next tag so pre-releases are not mistaken for latest. microsoft/types-publisher#365 seems like another example.

[kurtinatlanta]

@richseviora Thanks for your efforts. I'm sure this isn't what you wanted to spend your day on, so I appreciate the effort..

Did you do what I mentioned I did in my last post? Anyone doing npm install @types/react today is going to get the React 16 types, not the React 15 types. Anyone doing npm update will get @types/react updated to the React 16 types.

I get that types-publisher may not provide a way to specify the npm tag (though it should).

Part of my fun comes from transitive dependencies. We have Project A that depends on React, we have project B that depends on a set of components that depends on React. When these all get mixed together, the bad things start to happen. So it will take some time to pull together multiple packages that show interactions.

[richseviora]

@corydeppen - agreed it'd be ideal but it doesn't look like the capability exists today. single tear

@kurtinatlanta :) hey, I'm happy to help where I can :)

Re: trying to install new @types/react, yes I did. But I can't reproduce the compile error.

If you are still getting compile issues, can you reproduce the actual compile error in a test repo? I can't reproduce it myself in a clean repo, so I'm not sure that the issue is with the presence of V16 types with other repos that have a wildcard dependency on React so much. I think instead it is npm failing to handle the upgrade properly.

Otherwise, is it worth the effort to revert to V15? (assuming such a thing is supported) After all, the only change 16 made was to introduce an optional lifecycle method. Implementing it in components created under 15 would have no absolutely no effect.

[kurtinatlanta]

@richseviora I can try to find time to get a good test repo going. It does seem to happen more when I have multiple versions installed in node_modules like this:

$ npm ls @types/react
mdf-editor@6.0.0 /Users/hoytk/git/mdf-editor
├─┬ adp-mdf-components@6.1.20
│ └─┬ @types/react-virtualized@9.7.3
│   └── @types/react@16.0.1 
└─┬ adp-mdf-core@6.1.12
  ├── @types/react@15.6.0 
  ├─┬ @types/react-dom@15.5.2
  │ └── @types/react@16.0.1  deduped
  └─┬ @types/react-redux@4.4.47
    └── @types/react@16.0.1  deduped

With this error showing up for every React.DOM item (which usually means multiple versions installed):

    TS2403: Subsequent variable declarations must have the same type.  Variable 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.

This tends to happen after npm update, which goes and gets @types/react 16.0.x.

[richseviora]

Hi again! Apologies for the delay in getting back to this. Looking at this issue in yarnpkg, it looks like this resolution outcome is expected when the dependencies aren't marked as peer dependencies.

I think we need a policy answer from the admins here. Should/can we revert a type definition if it's been published in advance of the package itself being released?

Also, should definitions that depend on other definitions have those definitions be marked as a peer dependency?

[kurtinatlanta]

We updated all our projects to @types/react 16.0.2 and that has cleared things up for us, so it may have just been multiple versions in node_modules conflicting. I'm closing this for now.