Timeline for Prevent adding unwanted Dependencies to a Managed Package
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2021 at 21:44 | comment | added | David Reed | It is sometimes possible to remove a dependency from a 1GP release without reverting the package to a beta but it's highly fact-specific (based on the manageability rules of the components that create the dependency). | |
| May 20, 2021 at 21:43 | comment | added | David Reed | That's as far as I understand it mostly true. It's dependent on the OOTB shape of the build scratch org. In certain edge cases it's possible to create a dependency on a feature that is part of that OOTB shape but is not available in some customer orgs. Not particularly likely, but it is possible. | |
| May 20, 2021 at 21:28 | history | edited | sfdcfox♦ | CC BY-SA 4.0 |
added 119 characters in body
|
| May 20, 2021 at 21:27 | comment | added | sfdcfox♦ | @PhilW The main point, which I think was unclear here, is that in 2GP, you must explicitly create the dependency; each package is fully validated against its claimed dependencies in sfdx-project.json, so you can't possibly accidentally create a dependency. | |
| May 20, 2021 at 21:23 | comment | added | Phil W | Removing dependency in 2GP is just as difficult as in 1GP since you have to have folks uninstall otherwise they are then on a separate branch in your version tree (and do you really want to somehow keep both branches going)? Let's wait and see what SF does about metadata deletion in 2GP, when they get there... | |
| May 14, 2021 at 16:07 | history | answered | sfdcfox♦ | CC BY-SA 4.0 |