Module not found: Error: ember-tooltips is trying to import the app's @ember/string package, but it seems to be missing

[Turbo87]

In rust-lang/crates.io#9011 I'm trying to update @ember/string to the v4 release, but apparently that is causing the build to fail, claiming that the package is missing.

It looks like every single dependency in the ecosystem that is relying on @ember/string now needs to publish a breaking change release to update their dependencies, or am I missing something?

[NullVoxPopuli]

@ember/string @ v4 is a breaking change, and requires the following for older ember-ecosystem packages to to use v4

• ember-auto-import @ > v2 or embroider (or be a v2 addon)
• ember-source >= 3.28

Additionally packages using @ember/string, as of ember-source @ v5, must declare it in either their dependencies or peerDependencies

If all 3 of those conditions are met, then the @ember/string @ v3 to v4 migration can happen without a breaking change for each package using @ember/string

What packages, in particular are you noticing having issues?

[Turbo87]

sure, but why does updating the package in the app break the build for the addons that use the previous version?

[NullVoxPopuli]

I'd wager it's a compatibility mistake, due to the old way of doing things in broccoli land (or it's just a problem that's always been there, and is just now manifesting)

@ember/string didn't used to come from a package at all -- it came from the ether! (ember-source, as just a file).

Once all dependencies are v2 addons, the problem will cease to exist (which might be a while from now at the rate I'm going 😅 )
(especially because "in the world of old", package.jsons were incorrect)

I would experiment with pnpm's packageExtensions config to add @ember/string to dependencies trying to import from it.

Library-wise, what I think folks should do, is set their dependencies entry on @ember/string explicitly, and potentially set the version range to ^3.0.0 || ^4.0.0

[kategengler]

I'm hitting this upgrading to @ember/string v4 as well.
The app is on v5.8 with latest ember-auto-import and embroider.

This is the stack trace:

vendor.js:254 Uncaught 
Error: Could not find module `@ember/string` imported from `(require)`
    at missingModule (vendor.js:254:11)
    at findModule (vendor.js:265:7)
    at requireModule (vendor.js:31:15)
    at eval (?../../.pnpm/@embroi…my-app:1:18)
    at ../../.pnpm/@[email protected]_@[email protected][email protected][email protected]/node_modules/@embroider/babel-loader-9/index.js?{"variant":{"name":"dev","runtime":"browser","optimizeForProduction":false},"appBabelConfigPath":"/Users/katie/dev/my-app/node_modules/.embroider/rewritten-app/_babel_config_.js","cacheDirectory":"/private/var/folders/wq/_yzzcnwn3wlfm5x_6gg5d8vm0000gn/T/embroider/webpack-babel-loader"}!../../.pnpm/@[email protected]_@[email protected][email protected]/node_modules/@embroider/webpack/src/virtual-loader.js?f=%2F%40embroider%2Fext-cjs%2F%40ember%2Fstring&a=%2FUsers%2Fkatie%2Fdev%2Fmy-appi! (chunk.7677c78….js:357:1)
    at __webpack_require__ (chunk.ee17d04….js:1463:42)
    at eval (index-cc461d33.js:30:71)
    at ../rewritten-packages/@ember-data/store.ccec4f6a/node_modules/@ember-data/store/index-cc461d33.js (chunk.7b68ccb….js:1536:1)
    at __webpack_require__ (chunk.ee17d04….js:1463:42)
    at eval (index.js:13:73)
    ```
    

[NullVoxPopuli]

Looks like @ember-data/store needs to declare @ember/string in their deps.

[runspired]

Its more likely an outdated version of @ember-data/store

[kategengler]

It is indeed 4.12.8 of @ember-data/store (matching my ember-data version).

It is fine that I cannot upgrade this package but I wonder if we could make the errors more helpful somehow?

[amiarSlimane]

on ember 6.1.0 + @ember/[email protected] i had the issue with ember-changeset-validations,
Could not find module @ember/string imported from ember-changeset-validations/utils/messages and downgrading to @ember/[email protected] solved the issue

[NullVoxPopuli]

Alternatively, those dependencies could declare ember-string in their deps. Can you open issues on those repos?

Thanks!

[amiarSlimane]

Thanks for the suggestion , i have opened the issue on ember-changeset-validations#366 and ember-tooltips#461

[kategengler]

Updating a project from v5.10 -> v5.12 via ember-cli-update brings @ember/string v4 in the blueprint.

The project is on embroider, I get several errors:

ember-responsive is trying to import the app's @ember/string package, but it seems to be missing for various sets of addons. In this case ember-responsive hasn't been updated in awhile but does properly have a dependency but on @ember/string@3.

This is really a terrible upgrade experience. I can either try to go and update many outdated addons or I need to use something like patching the package to try to get everything onto @ember/string@4?

[NullVoxPopuli]

I think projects who are relying on v1 addons to have implicit imports resolve to real packages should probably stay on @ember/string @ v3.

@ember/string @ v3 is still compat with ember v5.x and v6.x

This is just a fact of how bad our v1 addons were. Too many assumptions 😬

[kategengler]

Still a bad upgrade experience with the update to @ember/string coming from the CLI blueprint

[NullVoxPopuli]

Sure, if only we could have the blueprint have more frequent breaking-just-in-case releases 🤔

[kategengler]

Sure, if only we could have the blueprint have more frequent breaking-just-in-case releases 🤔

I am not sure what this means.

[NullVoxPopuli]

If we try to keep the blueprint perfectly non-breaking for existing users, we can't make progress for new users.

Every time we add an addon at some version, it has the potential to break someone's build when they're relying on an old version. This would make upgrading between majors in the blueprints' package.json impossible, if we were to be that strict... and being that strict keeps the blueprint behind what we actually want folks to be doing in new projects.

It's more motivation, for @mansona's blueprint work, and, imo, a good argument for getting the blueprints out of ember-cli (even though @ef4 argues that it makes testing compatibility harder)