Simplified imports

[NullVoxPopuli]

trafficstars

From: https://github.com/emberjs/rfcs/issues/945 Discord convo: https://discord.com/channels/480462759797063690/518154533143183377/1140567005984989264 Super thanks to @GavinJoyce for getting this started :tada:

Current status:

• blocked on starbeam integration

What could help in the mean time:

• PRs to Glint to add more intellisense features
• For apps, see: https://github.com/emberjs/rfcs/pull/946#issuecomment-1685392130

[ef4]

Discussed at RFC review meeting, provided some general feedback to author with ideas. This is not concrete enough yet to advance.

[gossi]

I actually do like having all these imports. Yep, sometimes its a lot, but that makes all these dependencies visible (My maximum is 27 imports :trollface:).

The problem yet, is to remember where these imports are coming from. Basically, each and everyone I need to re-lookup. It's hard to tell, whether this is part of @ember or @glimmer, the boundaries have been blurred.

For what would help is Identity to these. Having glimmer to be "low-level" doesn't really match reality anymore, as nobody really can't tell what "low-level" means.

Asking (core) members, where a certain thing should live, let's say on modifier? There is no clear answer, this goes more like "hum, could be ember for this reason - or - could be glimmer for that reason".

For whatever the identity of @ember, @glimmer and @starbeam will be. Make it explicit, then the second effort is to figure out the package within that namespace - but that should then almost be done by instinct.

[NullVoxPopuli]

where a certain thing should live, let's say on modifier? There is no clear answer, this goes more like "hum, could be ember for this reason - or - could be glimmer for that reason".

for on, in particular, I'd like to propose it be built in. It's too fundamental for it to be living in "userland" (even if that userland is @ember/modifier).

. Basically, each and everyone I need to re-lookup. It's hard to tell, whether this is part of @ember or @glimmer, the boundaries have been blurred.

Exactly why I think it's worth exploring a unification of the imports. we have 2 main concepts, which should cover the 90%

• reactivity
• template utilities

beyond that you have other userland implementations of things, and that's where you get multiple imports (@glimmer/component, xstate, @nullvoxpopuli/my-crazy-experiment, etc)

For whatever the identity of @ember, @glimmer and @starbeam will be. Make it explicit,

I think one thing we've not been great at is defining which @ember and @glimmer are meant to be. A lot of things that should have been in glimmer, were pushed to @ember (or to the community), and likewise, a many of things in @ember, are very split up -- but partially because it's better to implement things as separate packages for concerns and tree-shaking reasons -- which is why we can explore this incrementally -- but only after we ensure that tree-shaking works. _I think partially to the point you're getting at (@gossi), is that it's easy to understand the source of truth when imports are as numerous as they are.

For folks that want reduced imports, it's perfectly fine, and codemoddable (from an ecosystem standpoint) to create re-exports, as @GavinJoyce has done. It makes sense because we currently don't have good auto-import / intellisense for the imports. We need to PR to glint to enable this. If folks type less, then the burden of typing is felt less.

Folks could choose to abstract their imports in their organization (hopefully only if they have good documentation or a small well-sync'd team):

// @my-app/reactivity
export * from 'ember-resources';
export * from '@glimmer/tracking';

// @my-app/template
export * from '@ember/modifier';
export * from '@ember/helper';
export * from 'ember-truth-helpers'; // if they provide nice gjs re-exports
export * from 'ember-whatever/sub-path-because-thats-whats-available';

there is no risk here (other than documentation) -- folks choosing to do this in large organizations may want to add a lint to auto-correct the direct imports to their app-local re-exports.