You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can't fix this in the core library because of NodeJS, Core-JS, ES6-Shim, etc. also defining these as symbol. I hope to get "lib" references in soon so that we can change NodeJS et. al. to reference the definitions in lib.es2016.symbol.wellknown.d.ts and then make this change.
We unfortunately run into collisions in type definitions for packages like NodeJS that forward-declare some symbols. #26568 would help us to get to the point where the NodeJS type definitions could use /// <reference lib="..." /> without breaking in older versions of the compiler.
#24738 fixes this gracefully with older versions of the node.d.ts by just assuming that if you wrote symbol under the global SymbolConstructor you meant to say unique symbol.
#24738 fixes this gracefully with older versions of the node.d.ts by just assuming that if you wrote symbol under the global SymbolConstructor you meant to say unique symbol.
I know we considered this, but it was more of a workaround. We need something like #26568 for other reasons and its more maintainable going forward.
That won't really help the community upgrade as much, though - they'll be forced to try and update their entire type heirarchy to depending on the latest version of all the declaration files. The workaround has the advantage that older declaration files continue to work (and continue to work with older versions of TS) and can be updated as needed.
they'll be forced to try and update their entire type heirarchy to depending on the latest version of all the declaration files.
This is usually the case when types are updated in a dependency. On definitely typed there are only a handful of packages that introduce this kind collision, which we can address easily enough once #26568 has landed in a development build. I'm not saying that the symbol to unique symbol workaround might not still be needed, but its possible it won't be.
Activity
RyanCavanaugh commentedon Feb 5, 2018
@rbuckton thoughts?
falsandtru commentedon Feb 5, 2018
If we do this update, we need a fix like #20018.
rbuckton commentedon Feb 5, 2018
We can't fix this in the core library because of NodeJS, Core-JS, ES6-Shim, etc. also defining these as
symbol
. I hope to get "lib" references in soon so that we can change NodeJS et. al. to reference the definitions inlib.es2016.symbol.wellknown.d.ts
and then make this change.RyanCavanaugh commentedon Aug 22, 2018
@rbuckton lib references are in, what should we do here?
rbuckton commentedon Aug 22, 2018
We unfortunately run into collisions in type definitions for packages like NodeJS that forward-declare some symbols. #26568 would help us to get to the point where the NodeJS type definitions could use
/// <reference lib="..." />
without breaking in older versions of the compiler.weswigham commentedon Aug 23, 2018
#24738 fixes this gracefully with older versions of the node.d.ts by just assuming that if you wrote
symbol
under the globalSymbolConstructor
you meant to sayunique symbol
.rbuckton commentedon Aug 23, 2018
I know we considered this, but it was more of a workaround. We need something like #26568 for other reasons and its more maintainable going forward.
weswigham commentedon Aug 23, 2018
That won't really help the community upgrade as much, though - they'll be forced to try and update their entire type heirarchy to depending on the latest version of all the declaration files. The workaround has the advantage that older declaration files continue to work (and continue to work with older versions of TS) and can be updated as needed.
rbuckton commentedon Aug 23, 2018
This is usually the case when types are updated in a dependency. On definitely typed there are only a handful of packages that introduce this kind collision, which we can address easily enough once #26568 has landed in a development build. I'm not saying that the
symbol
tounique symbol
workaround might not still be needed, but its possible it won't be.ntninja commentedon Sep 13, 2018
Sorry for being a bother, but now that #26568 has been merged, is it possible to revisit this for TS 3.1?
ExE-Boss commentedon Jan 3, 2020
#24738 would fix this in a manner that’s compatible with old
.d.ts
files.4 remaining items