Problems running ember-try on v2 addon blueprint

[jrjohnson]

🐞 Describe the Bug

I think there might be an issue with publication for 6.0.0-beta.1. Running pnpx ember-source-channel-url canary gives https://s3.amazonaws.com/builds.emberjs.com/beta/shas/fab7a68bd6b491e803e46a6d1190948cf6e1986b.tgz downloading that file the version in package.json is 6.0.0-beta.1.beta+fab7a68b which has an extra .beta on the end compared to what is in npm

The error that I'm seeing in my addon ember-try build is No matching version found for [email protected].

🔬 Minimal Reproduction

Can be duplicated with

ember addon my-addon -b @embroider/addon-blueprint --pnpm
cd my-addon
pnpm --filter my-addon add ember-concurrency
cd test-app
./node_modules/.bin/ember try:one ember-beta

I used ember-concurrency here, but installing any addon with peerDep on ember-source will fail in the same way.

😕 Actual Behavior

Try build fails with a dependency error.

🤔 Expected Behavior

Try build should succeed (or at least run)

🌍 Environment

• Ember-CLI: 5.12.0
• Node.js/npm: v20.18.0 / pnpm: 9.12.1
• OS: OSX

[fdeters]

I noticed my try-scenarios CI job failing on ember-release, ember-beta, and ember-canary, and I believe it's the same issue. My builds fail with the following PNPM errors:

ember-release

 ERR_PNPM_NO_MATCHING_VERSION  No matching version found for [email protected]

ember-beta

 ERR_PNPM_NO_MATCHING_VERSION  No matching version found for [email protected]

ember-canary

 ERR_PNPM_NO_MATCHING_VERSION  No matching version found for [email protected]

I was also able to reproduce using @jrjohnson's steps above.

[kategengler]

I believe this is due to us changing the tag naming and our build outputs. Looking into it.

[kategengler]

Fwiw the extra .beta is not the issue -- that's how it always has been for builds on s3.

[kategengler]

@jrjohnson or @fdeters Do either of you have a failing build you can link to for debugging?

[fdeters]

@kategengler my original is not public, but here's a repro that's failing in the same way (using a fresh v2 addon from the blueprint and installing ember-concurrency in the addon). It should be public, but let me know if you can't access it: https://github.com/fdeters/ember-try-repro/actions/runs/11863260316

You can see the previous job completed successfully before I added ember-concurrency.

[kategengler]

Thanks for the reproduction -- that helps a lot.

I confirmed that there is no problem with ember-try with v1 addons using either npm or pnpm, with or without ember-concurrency added.

I went to see if this were a problem with the v2 addon blueprint with just npm and I encountered the a similar issue even without ember-concurrency.

Running ember try:one ember-canary --skip-cleanup

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]+1a632422
npm ERR! node_modules/ember-source
npm ERR!   dev ember-source@"https://s3.amazonaws.com/builds.emberjs.com/canary/shas/1a6324222fcc9606becb0fb89d3698bfc3436394.tgz" from [email protected]
npm ERR!   test-app
npm ERR!     [email protected]
npm ERR!     node_modules/test-app
npm ERR!       workspace test-app from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer ember-source@">= 4.0.0" from @ember/[email protected]
npm ERR! node_modules/@ember/test-helpers
npm ERR!   dev @ember/test-helpers@"^4.0.0" from [email protected]
npm ERR!   test-app
npm ERR!     [email protected]
npm ERR!     node_modules/test-app
npm ERR!       workspace test-app from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

ember-try modified the package.json as follows:

-    "ember-source": "~5.12.0",
+    "ember-source": "https://s3.amazonaws.com/builds.emberjs.com/canary/shas/1a6324222fcc9606becb0fb89d3698bfc3436394.tgz",
     "ember-source-channel-url": "^3.0.0",
     "ember-template-lint": "^6.0.0",
     "ember-try": "^3.0.0",
@@ -79,5 +79,8 @@
   },
   "ember": {
     "edition": "octane"
+  },
+  "overrides": {
+    "ember-source": "$ember-source"
   }

The overrides in the past has been what has handled these peer dep issues. Any thoughts @mansona ?

[ef4]

@mansona discussion at the tooling team meeting did not surface much more detail, we're just going to need to run the reproductions and debug.