-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add missing @ember/string
dependency to peers
#501
Conversation
this should fix build error when using
|
@Techn1x can you push again? I just re-enabled CI -- so we'll be able to see if this is a safe change to make |
646fcad
to
a0c581c
Compare
sure! pushed |
Hm, in order to make sure we don't break things, we need ci to be green first. Would you be willing to fix it in separate prs? |
Oh no! I can take a look tomorrow (Australia 🦘). Ideally I wanted this to be a patch so that downstream consumers just get it without much hassle But to get CI working it looks like we would need to drop some old versions of node, I hope it's not much more complicated than that. But I think that would then require cutting a major, and downstream consumers aren't likely to get that updated quickly (would need to update dependencies of repos like mirage) Any advice? Is that the best way to go? Maybe we first make this a smaller PR that just lists the ember/string V3 dependency, cut a patch release (assuming it is OK), then a major which widens to ember/string 4 and drops old node versions? |
I wonder if it's possible to pin whatever requires newer node? since, I assume at one point, CI was green? |
I think the problem is here: Lines 89 to 92 in 7da42ab
maybe replacing to v16 helps already to get green ci?
|
so the v2 conversion PR (I was just re-looking at it) does have green CI -- but would also be a breaking change -- and it also needs to add so in order to get a fix out for ember-inflector in a non-breaking release, we need to not make the breaking change here (else just make all the breaking changes at once, such as in @mansona's v2 PR) :-\
I fear that the only way around stuff like this is increasingly aggressive overrides/resolutions on the super old versions on those libraries |
tested shortly updating node to v16... with that change you get already some tests green, but not all.. the problem is, you run into issue of Looks like bringing this to the finish will be more work... |
yea, we'd probably have to remeove ember-release/beta/canary from the try matrix, and/or swap them out with what actual versions would have been
<3 compatibility often is monotonous |
you can rebase this now that #502 is merged 👍 |
a0c581c
to
9796fb7
Compare
Wow, a lot happened while I was sleeping! 😄 Rebased! |
so looking at the failures and trying to figure out exactly what the situation is 🫠 I think our best bet is to actually just make this have a dependency on if we want this to be a non-breaking fix then I think that's the only way forward 😞 |
I'm not so sure, in order to be using this addon, users would have had to have ember/string installed in their projects right? So a peer makes sense? I think we just have to add ember/string to those ember-try scenarios? |
I think you might be right, it's worth testing... But it would then need to be a breaking change anyway 🤔 |
@@ -37,7 +37,7 @@ | |||
"@babel/eslint-parser": "^7.21.3", | |||
"@babel/plugin-proposal-decorators": "^7.21.0", | |||
"@ember/optional-features": "^2.0.0", | |||
"@ember/string": "^3.0.1", | |||
"@ember/string": "^4.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ember/string
@ v4 can't support ember-source < 3.28
So... it might be impossible to use @ember/string
@ v4 until we do a modern version of ember-inflector (which @mansona already has a PR for)
@@ -37,7 +37,7 @@ | |||
"@babel/eslint-parser": "^7.21.3", | |||
"@babel/plugin-proposal-decorators": "^7.21.0", | |||
"@ember/optional-features": "^2.0.0", | |||
"@ember/string": "^3.0.1", | |||
"@ember/string": "^4.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder though if it would work if we set this to @ember/string: ^3.0.0 || ^4.0.0
and configured the exact version in the try config.
also, I feel like someane already said that, and I'm too scattered today :(
Update ember-try.js
Update ember-try.js
Update ci.yml
Sorry for the commit mess, have been doing this from my phone. Added 5.4 and 5.8 try scenarios to make sure they work, and fixed up ember 3.x scenarios by listing ember/string 3. It seems that for ember 5.x onwards they need to use ember/string 3, based on an experiment branch I have elsewhere. So I figured I would remove ember/string 4 for this work and leave that to the major, but this is where I had to stop for now, can't run npm install from a phone 😛 I'll be at my desk in a few hours. Regardless, I'd like to propose a radical alternative;
This addon already has its own regex for camelize etc. so let's just replace this capitalize usage with the same regex from ember/string? ember-inflector/addon/lib/system/inflector.js Line 313 in 420e910
|
I'll put together a seperate PR to see what that looks like as an alternative. It should be the safest, least hassle option |
Done! I reckon this is a better way forward #505 |
fixed in #505 |
Resolves #347
This addon uses
@ember/string
but it is not listed in its package json file.With strictier package managers these days (like pnpm) we need to make sure this is correct.
This addon should have little opinion on the ember/string version used, so I've allowed for v3 or v4 in the peer dependencies.