Open NullVoxPopuli opened 8 months ago
Can you link me to where they say it's correct?
Have we tested what happens if the addon itself includes a import "ember-source/types"
in its own code? Does that make the triple-slash references go away? (That would still not be ideal but would at least be consistent.)
I wonder if tsc is smart enough to not do this if ember-source was using package.json exports to force these files to be private? Surely under those conditions it would be wrong to directly access them from typescript.
Can you link me to where they say it's correct?
Specifically:
Have we tested what happens if the addon itself includes a import "ember-source/types" in its own code?
I hadn't, because that would mean min-supported version would have to be ember-source@4.8
, and imo, not enough people or off 3.28 yet.
But I just tried it on ember-page-title (moving the import "ember-source/types"
from unpublished-development-types/index.d.ts
to src/index.ts
and disabling the part of the inline rollup plugin in that PR to remove the references -- and the /// <reference
lines came back -- so I don't think import location makes a difference.
The fix I've implemented is also not ideal, because I don't know what the consequences of .d.ts.map
files are -- I've had a hard time verifying .d.ts.map
usefulness, and don't have a good way to verify one way or another.
For some papertrail / history, her are other occurrences of this problem:
Starting back in August, 2023:
grep
+ sed
to remove the ///
EmberObject
types (which is before TS 5.3, so the probably will likely creep back in if that package releases again)EmberObject
-inheriting things (EmberComponent
in this case)Also (duplicate issue reports)
Last fix related to this problem here: https://github.com/ember-cli/ember-page-title/pull/283
Not sure what to do, as TypeScript says the behavior (of including references) is correct, so that means we kinda have to work around it.