Improve consistency of addons in this org for maintenance

[MelSumner]

There are a lot of times when I struggle to update or release one of these addons (in the org) because they're all using different configurations.

I'd like to propose that we adopt these standards:

• The primary branch of all repos is main
• All packages use pnpm
• All packages use release-plan (setup instructions here: https://github.com/mansona/create-release-plan-setup)
• ensure each repo has a consistent github ci workflow file
• ensure each repo is using ember-try
• use dependabot, use consistent config

For settings:

• update settings so a PR is required
• branches should be deleted after merge
• we'll add a consistent social preview image to each repo

If an addon should be archived:

• file an issue on that repo and let us know in the Discord channel

Did I forget anything?

cc @adopted-ember-addons/admin

Tasks

Preview Give feedback

1. Create template maintanance project
2. Update documentation for this org
3. Add project to each repo in org

[MelSumner]

Just as an FYI, here's a sample of what the preview images look like, generated in Canva:

[gilest]

Everything sounds good

Preview images look cool 😎

use dependabot, use consistent config

One thing I would miss about switching from renovate is the lockFileMaintenance and automerge features. I'm pretty sure dependabot doesn't have these

Suppose we could do that with scheduled GitHub actions, though 🤔

[knownasilya]

I like all the suggestions as well.

Could we do the preview images in like a shared figma file or something?

[MelSumner]

@knownasilya I have a team Canva account, if you don't mind using it I can add you to "the team"

Also if we can get the exact same results in a Figma file I don't mind that either!

[RobbieTheWagner]

I'm unfamiliar with release-plan and I tend to use release-it everywhere, but otherwise I agree with everything here 👍

[NullVoxPopuli]

imagine having even less work to do -- that's release-plan 🎉

[knownasilya]

Yeah release-plan rocks @RobbieTheWagner

[RobbieTheWagner]

I'm skeptical that it could be less work because all I do is run the release-it command, but I'll check out release-plan.

[NullVoxPopuli]

With release-plan, I can release from my phone from anywhere. Anywhere. And so can anyone with merge access. No need to add a ton of folks to npm. No CLI needed.

In the car? do a release
In a meeting? do a release
In line for coffee? do a release
Going #2? do a release

lol. <3
If you want a demo, I can set that up, I need to release test-helpers early next week

[MelSumner]

@NullVoxPopuli would you be willing to record a short demo?

[josephdsumner]

Really excited to see initiative for this! Thanks @MelSumner :)

I agree with the tooling choices across the board, let alone the standardization of them across the org.

Would it be appropriate to earmark a check-in on the tooling standards when ember source crosses a major / when larger-scale migrations need to take place?

[herzzanu]

This looks great, @MelSumner 😍 thanks for the suggestions. Do you plan to create a project where we can plan and track the work needed to achieve these suggestions? I'd be happy to contribute 🙌

[NullVoxPopuli]

a short demo?

after merging a PR,
https://www.youtube.com/watch?v=dEtMm2HQTAE

[MelSumner]

@herzzanu that's a great idea. I will try to have something up by this weekend unless anyone else in the group has any objections we need to work through.

[jelhan]

I fully agree that we need to standardize. My last attempt trying to do so got stuck.

Two points:

1. Rollout is key. A formal standard not implemented in majority of the apps does not help much.
2. We should clearly document it.

For documentation, we should either update the existing Standardizing Addon Maintenance in the program guidelines or replace it with another document.

I would recommend discussing the concrete technical proposals in separate PRs updating a reference document. I feel it is too many technical details to discuss all of them in one GitHub issue.

[MelSumner]

I'm working on the template project: https://github.com/orgs/adopted-ember-addons/projects/2/views/1

The idea is that this can be used as a template to create new projects in each repo, which will hopefully reduce the amount of redundant work to do the necessary work for each repo.

[darrenw-npi]

I like almost everything about this. However unless / until pnpm becomes the default in Ember (in the documentation and for new projects) then I think this creates confusion and friction. I personally prefer pnpm but the Ember package manager situation is already confusing.

[MelSumner]

@darrenw-npi this is useful feedback, thank you! The impetus for using pnpm was more a side effect of trying out release-plan and having a PR that moved an addon to pnpm first.

@mansona and/or @NullVoxPopuli can you speak more specifically why pnpm ?

[NullVoxPopuli]

pnpm provides all the tools you need to be productive, while also being fast and least wrong.

Yarn is no good because it literally has no idea how to manage dependencies, and everyone should absolutely migrate off of yarn@v1

npm and yarn4 are ok, but they're under funded, and don't provide all features you need to work with the jank that is in the broader ecosystem.

In particular, how pnpm helps you work around (and with maintainers!) is with these features:

• https://pnpm.io/package_json#pnpmpackageextensions
• https://pnpm.io/package_json#pnpmpeerdependencyrules
• https://pnpm.io/cli/patch

[darrenw-npi]

I'm 100% in agreement with @NullVoxPopuli and it was his recommendation to get off yarnv1 that got me out of a massive hole when upgrading an Ember app. My concern was that if Ember itself and adopted add-ons are using a different package manager it would be a pain for Ember users to switch package managers. In hindsight I think that would only be an issue for those who are core and adopted add-on developers so probably only a small issue for a small number of developers/users.

[darrenw-npi]

I do think as a wider issue though it would be great if we could settle on a default/recommended package manager across the whole Ember ecosystem. I would have no problem with this being pnpm.

[MelSumner]

I do think as a wider issue though it would be great if we could settle on a default/recommended package manager across the whole Ember ecosystem. I would have no problem with this being pnpm.

I think it's going to be a turns and roundabouts kind of thing, TBH. I've noticed that the community tends to coalesce on things that work really well, and those things become "the way" to do it, then they break so everyone moves to something else, and time marches on.

But I absolutely share the same wish to make things more standard across the board, which is the heart of this proposal. I want to make it more consistent, and in theory therefore easier, to maintain these adopted addons. I'm hoping that will help make it easier not only for the core maintainers of these addons but also for the casual volunteer. I consider myself to be a casual volunteer, TBH; while I came up for the initial plan to have a place for addons to go, I still find myself struggling with all of the differences between the addons when someone asks for a release and I'm just trying to help do that.

So hopefully, having some consistency around the addons that end up in this org will benefit the ecosystem all around. Does that make sense?

[NullVoxPopuli]

settle on a default/recommended package manager across the whole Ember ecosystem.

npm will always be supported by the blueprint-outputs since it is the default with node.
We could even say that we try to use npm@10+ until we need pnpm.

We'd need to make sure we just configure npm to always be in the strictest available mode for dep/peer checking, and not allow any permissive forgiveness.

As library developers, we don't want our users to discover dep mishaps before we do 😅

[mansona]

So I tend to always want to use the "defaults" for most things because I like the fact that we're testing out the situation that most developers are going to find themselves in.

I would suggest that standardising on pnpm for adopted-ember-addons is a different question though. It is likely that a small(ish) number of developers are going to be jumping between a number of adopted-ember-addons and in this case it will greatly improve the lives of those developers because of the way that pnpm shares dependencies between projects.

I think it is always fine for us to pick the tool that helps us the best as long as it's clearly documented in the CONTRIBUTING.md file. The only change here is that we're going to be moving from one non-default (yarn) to another non-default (pnpm) in most cases, so we're probably not introducing new friction here.

The one thing to be very clear about here is that we should not be using yarn@1 for any of our projects. I would be ok with a policy that says "Anything using yarn@1 should switch to pnpm, but npm projects can stay on npm" but that also defeats the purpose of standardising across the org.

Anyway that's my 2c 👍

[MelSumner]

Thank you @mansona and @NullVoxPopuli !

Also h/t to @adam-coster for this great explainer article: https://adamcoster.com/blog/pnpm-config