[BUGFIX beta] Add ember-auto-import 2

[ef4]

Closes #19752

This solves that because ember-auto-import 2 already provides the required assertion.

[simonihmig]

This causes failing Canary CI builds for addons that still use e-a-i v1: Error: To use these addons, your app needs ember-auto-import >= 2: ember-source.

I think this can be fixed by adding v2 (and webpack) to the devDependencies of the canary ember-try scenario. However that approach is a bit fragile, as the other "floating" scenarios (beta, release) would at some point also be affected by this, so the best would probably be to do that prematurely for them as well!?

This will likely cause some churn in the ecosystem, for all addons that haven't jumped to v2 yet, and maybe aren't ready yet to do that major bump. Thoughts?

[rwjblue]

I think this can be fixed by adding v2 (and webpack) to the devDependencies of the canary ember-try scenario.

I think the best fix is to add webpack@5 and ember-auto-import@2 to the devDependencies of the addon's in question. If you do this, you won't need to do anything with the ember-try scenarios at all.

That change was landed in ember-cli here ember-cli/ember-cli@20b71db, and will be released in the upcoming ember-cli@4.0.0-beta.1.

[simonihmig]

I think the best fix is to add webpack@5 and ember-auto-import@2 to the devDependencies of the addon's in question

Will that work when the addon already has eai@1 in its dependencies? (and is not ready yet to do the major bump, but still wants a green CI)

[ef4]

Will that work when the addon already has eai@1 in its dependencies?

Hmm, that's a good point. This is a place where the mixed nature of dummy apps is going to cause unnecessary pain.

What you really want is your addon having a dependency on eai 1 and your dummy app having a dependency on eai 2. That would work cleanly and let you test your addon under ember 4, without upgrading the addon's own dependency. But dummy apps mix up all the dependencies between the app and the addon. @rwjblue would know better, but I don't think there's a way to prioritize between dependencies and devDependencies such that it would have the right effect, if you use a regular dummy app.

On the other hand, the cost vs benefit to upgrading to eai 2 in your addon makes the upgrade pretty worthwhile. We've seen even very large apps upgrade with very little effort, so it's not imposing much cost on your users. Plus there is a significant build-time performance benefit starting at eai 2.2, and it scales with the number of addons that upgrade.

[simonihmig]

This is a place where the mixed nature of dummy apps is going to cause unnecessary pain.

💯 (yet again, we have to say... 😔. )

On the other hand, the cost vs benefit to upgrading to eai 2 in your addon makes the upgrade pretty worthwhile

Yeah, I do want to do that, for the addon I was working I planned a major bump anyway. But there might be reasons for other addons to not do this yet, and those will run into those failing CI builds now. Just wanted to mention this, as it might cause some confusion for probably a lot of maintainers!?

[jherdman]

I want to chime in as one of these maintainers. We have a bunch of internal addons with EAIv2 upgrade ticketed for "the near future" ™️ . Failing canary builds aren't a huge deal insofar that we know and understand why it's happening, but it's not fun having a bunch of failing canary builds.

[ef4]

To just get passing canary builds, the earlier suggestion to put ember-auto-import 2 and webpack inside the ember-canary ember-try scenario is a good solution:

{
  name: 'ember-canary',
  npm: {
    devDependencies: {
      'ember-source': await getChannelURL('canary'),
      'ember-auto-import': '^2.0.0',
      'webpack': '^5.0.0'
    },
  },
},