-
Notifications
You must be signed in to change notification settings - Fork 43
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
Proposal: ember-cli-deprecation-workflow 3 #169
Comments
Hey thanks for this list 🎉 I have a few questions/comments about some of the specifics:
Is there any particular reason why we're not intending to make this Node 18 since v16 was EOL'd on 2023-09-11 ?
Do you have more info on the motivation behind this? We have recently removed volta from our test suite in Embroider because it was giving us so much grief. We found that the lockfile was good enough to pin the behaviour of pnpm locally and it also supports defining a version of Node directly in your |
Eh, we could. In general this kind of library is intended to help codebases on very old versions bridge the gap to newer versions. So I think some dragging of the feet for minimal version support is probably a good idea.
I'm not familiar with pnpm's pinning functionality at all. I thought Node's infra is what kept falling over with Volta. Volta still lacks support for pnpm I just realized. Lame https://docs.volta.sh/advanced/pnpm Yay that pnpm lockfile is supported by dependabot though! dependabot/dependabot-core#1736 |
The first two checkboxes here can be checked I think! One related minor cleanup PR: #181. With all broccoli dependencies removed, I think we could turn this addon into v2 format, couldn't we? As we don't have a dependency on ember-auto-import currently, this would be strictly speaking a breaking change (although probably nobody notice, unless they are light years behind), so something we should do before bumping the major! Also this: #182 |
@simonihmig are we able to convert this to a v2 with the fact that we still need the vendor support to be able to catch deprecations in vendor code? |
v3 is released, so this can be closed? |
@mansona Sorry for the late answer, missed that. I think that vendor stuff needs to go for v2. But do we really need that anymore? Looking back at the discussion here, this seems to have minimal impact, only for rather, obscure cases, or do I misunderstand that? Do we have any idea if there are any concrete deprecations affected by this that people might still run into these days (in not completely out of date codebases)? As this is going to be added to the app blueprint here, and we want at least the v2 app to be v1-free, I don't see a good reason to not migrate to v2 and cut a new major release, dropping that vendor stuff. Any disagreement?
Yeah, above thread is tangential, but as v3 is released indeed, I'll close this. |
This issue proposes a major version release of ember-cli-deprecation-workflow: v3.0.0
The aims of a 3.0 are:
vendor.js
based implementation to one where the dependency must be manually added toapp.js
. [BREAKING] Convert to a module. Drops support for Ember < 3.28, requires manual initialization #159pnpmnpm Bump Node, swap to npm, update CI pipeline #170ember-cli
org (oremberjs
org?)3.0
Any other suggestions or concerns?
The text was updated successfully, but these errors were encountered: