Stop publishing types
chriskrycho opened this issue · 1 comments
We recently discovered internally that the fact that this is publishing types can cause apps and addons which use TypeScript to end up very confused, depending on exactly how they end up resolving the @ember/string types module graph. If they resolve to the types published here, for Ember 3.8, they will always error.
example type error
node_modules/@types/ember/index.d.ts:446:46 - error TS2339: Property 'htmlSafe' does not exist on type 'typeof import("/Users/ckrycho/dev/linkedin/ember-restli-graphql/node_modules/@ember/string/index")'.
446 const htmlSafe: typeof EmberStringNs.htmlSafe;
~~~~~~~~
node_modules/@types/ember/index.d.ts:447:48 - error TS2339: Property 'isHTMLSafe' does not exist on type 'typeof import("/Users/ckrycho/dev/linkedin/ember-restli-graphql/node_modules/@ember/string/index")'.
447 const isHTMLSafe: typeof EmberStringNs.isHTMLSafe;
~~~~~~~~~~
While it would be nice to fix this simply by fixing the type definitions, we should instead remove the type definitions for now. This will fix the existing issue here, and align us with our current support policy for TypeScript, which is that core Ember addons should not publish types at present: we do not have any stability guarantees around them or their relationship to SemVer!
(I plan to address that with an RFC in the very near future, however, and this repo would be a prime candidate for rolling out support when we do.)
A bit of elaboration: I believe the problem arises in this specific scenario because of how the timeline ended up playing out as regards the @ember/template package and the way this and that one both exported HTMLSafe and isHTMLSafe at times. This is another useful data point into the design for SemVer stability around our ambient types, as we currently publish types in DefinitelyTyped which say that those are available on the namespace for Ember.String, which (if my spelunking is correct) resolves to this module.