It is complex, confusing and inefficient to have perennial and perennial-alias

[samreid]

It is complex, confusing and inefficient to have perennial and perennial-alias. Now that we have more functionality in perennial (linting, grunt tasks, node modules) this problem is increased.

Each time a developer needs to make a change in perennial, they need to think carefully about whether to change the copy in perennial or perennial-alias. Then after making the change, and pushing, they need to be careful to pull the other repo. When a change is needed in both, the developer must take care not to push both.

[samreid]

One solution to this problem may be:
Can we eliminate perennial-alias and allow perennial to depend on phet-core via a parallel checkout?

Discovered in phetsims/chipper#1464

One idea @jonathanolson and @zepumph and I discussed is:

• Get rid of perennial-alias
• Change the perennial tooling so that it operates on a separate parallel working copy rather than in-place

perennial-alias has been a point of complexity and confusion, and would be good to eliminate. We discussed that developers could have one working copy which is always on main, and another which is allowed to operate on shas, branches, etc.

However, this would:
a) be a huge development effort since perennial has many complex tasks that currently assume they can operate locally
b) would introduce complexity for sim developers who would need to check out 2x trees of everything and know when to run tasks from phet/checkouts/main vs phet/checkouts/working

I just wanted to write the idea down, knowing that it is likely too expensive to implement. But it is the first viable alternative to perennial-alias that we have considered, which would also allow perennial to use code from phet-core or axon, etc.

[zepumph]

@jonathanolson and @samreid and I spoke about this again today, and we want to gather more information by investigating #401. From here we can learn if having a codebase where "all branches are always on main while executing perennial commands" is possible.

[zepumph]

One path forward that @samreid and I just thought of is to center all of our code around perennial-alias. perennial is the odd case, because it always stays on main, and we shouldn't promote other repos to be "always on main". Instead our whole codebase should depend on just one copy of perennial, and perennial can only use and be used by itself. Likely there are other exceptions, but in general, "you need a good reason to use perennial." Mostly we should just use perennial-alias.

[zepumph]

We spend 2 hours brainstorming with @jonathanolson over in #401 (comment) and didn't find a better solution that perennial-alias. All other ideas would require lots of work to change things, but then (mostly) still have trade offs and challenges for maintenance, deploys, and developer training. We are ready to close this issue and continue with perennial-alias indefinitely.