Template tag codemod stability fixes

[void-mAlex]

documents codemod usage in readme
fixes case when codemod is run against stable build of an app
make codemod work oob without failing on self resolvability

[mansona]

Looks like some good fixes, I've just added some micro comments that I'm fine with us fixing after this is merged since it's such a benefit to update the instructions

[void-mAlex]

I would imagine this is a bugfix rather than an enhancement but I defer to you @mansona

[mansona]

@void-mAlex your changes to externalNameHint I think warrant the enhancement label but it doesn't really matter since everything is being released as an alpha at the moment 😂

[ef4]

We discussed making this configurable.

I think the new default behavior here is debatable. I don't like it because namespacing on component names is an old habit based on having all components in one big global pool. Now that they're imported, it's not great style.

By analogy, which of these do you do?

import { uniq } from 'lodash';
import { uniq as lodash_uniq } from 'lodash';

The default here is equivalent to the second one of those.

A better default for namespaced stuff would probably be dropping everything before the last ::.

// before
<Widgets::Big />

// after
import Big from './widgets/big';
<template><Big /></template>

[NullVoxPopuli]

Agreed. Namespacing by default doesn't make sense today

[ef4]

This is not good. It leaves the bug behind to bite us again anytime there's version skew between the embroider that wrote node_modules/.embroider and the embroider that's running. We should use a version marker instead.

[ef4]

This is mutating the package cache. It might happen to work, but it changes the meaning of the package cache from an optimization to a correctness requirement.

I'm in favor of auto-fixing this problem for users, but we should do it by writing their real package.json. Not trying to maintain an inconsistency in the package cache.

[ef4]

I merged this into my other PR which includes test coverage, and this PR causes helpers like t to become capitalized. I think that's going to drive people nuts.

Let's take another stab at this PR, but I'm reverting for the present.

[mansona]

I reopened this PR here #2280 sorry for the confusion everyone 🙈

[void-mAlex]

We discussed making this configurable.

I think the new default behavior here is debatable. I don't like it because namespacing on component names is an old habit based on having all components in one big global pool. Now that they're imported, it's not great style.

By analogy, which of these do you do?

import { uniq } from 'lodash';
import { uniq as lodash_uniq } from 'lodash';

The default here is equivalent to the second one of those.

A better default for namespaced stuff would probably be dropping everything before the last ::.

// before
<Widgets::Big />

// after
import Big from './widgets/big';
<template><Big /></template>

namespecing is actually more important now in the new world order where we have

import { hash } from '@ember/helper';
import { hash } from 'rsvp';

and these are far from the only examples and they will be pushed to the extereme once route templates gain traction

namepsacing is also a closer to existing behaviour that people are used to with the framework
ask too much change at once and it will reflect negatively in the experience they have with the new format
I agree that having the option for shorter names should be presented but I strongly believe the ootb experience should the the one closer to what people are already familiar with to make the transition smoother

while you may have your opinions on what may or may not make sense in a gjs world fact is if you're using this piece of code to do transformations chances are you have an older codebase with namespacing folders in place and there is a high likelyhoold of multiple Cards/Card/Slideup in skeleton/provider/loader etc variants and having that be preserved is much more valuable than haing a poorly mangled Card/Card0/Card1 name