In 6.1-alpha, importing ember-source/types doesn't work, but the types: [] method does

[NullVoxPopuli]

idk if this is just how TS is changing, but in one PR: NullVoxPopuli/limber#1864

I noticed that all of the import 'ember-source/types' lines no longer define the types of the ember-source modules.

Now, I know the blueprint, and other ecosystems have been preferring types (in tsconfig.json#compilerOptions#types):

"types": ["./node_modules/ember-source/types/stable"]

it's just a bit lengthy as this doesn't respect package.json#exports.

It is suspicious that changing the ember version caused the difference in behavior.

[simonihmig]

Shouldn't the exports have to cover these type imports, seems there are not? https://github.com/emberjs/ember.js/blob/main/package.json#L8-L12

[NullVoxPopuli]

correct -- and fwiw, ember-data has been having the same problem (for much longer) -- finding that their type declarations are only loaded via this types: [ ./node_modules/* ] sillyness.

So, I wonder if, in order to support types: [ "pkg/export-name" ] or import 'pkg/export-name', we're missing something in our declaration output in both ember-source and ember-data's packages.

It could be that we really do need this form of exports?:

exports: {
  "./*": {
    "types": "....",
    "default": "...."
  }
}

rather than the shorthand.
And maybe "typesVersions" is what stopped worked in TS?

[simonihmig]

Wouldn't an additional entry like "./types/*": "./types/*" work?

And maybe "typesVersions" is what stopped worked in TS?

AFAIK, this is used if you don't have some "modern" value for moduleResolution like node16 or bundler. So either exports or typesVersions is used, depending on that config.

[Windvis]

correct -- and fwiw, ember-data has been having the same problem (for much longer) -- finding that their type declarations are only loaded via this types: [ ./node_modules/* ] sillyness.

FWIW, EmberData chooses to not publish the type exports config until the types themselves are considered stable, so the ./node_modules/ prefix is needed for that reason.

I ran into that EmberData issue when integrating the official types in the blueprints: ember-cli/ember-cli#10506 (comment)

I couldn't really find documentation about this in the TS docs, but it did seem that once an exports config is present, a types key needs to be in there for things to work without prefixing it with the actual path (which depends on your package manager, I guess).

Discussion: https://discord.com/channels/480462759797063690/1290318997040005234/1290367110744379445

[NullVoxPopuli]

Fix here #20792