Open Mattue opened 3 years ago
@Mattue sorry not sure I got your point.
Are you saying that if your sfdx-project.json
file reference a version 1.3.3.LATEST
it will install it even if a version 1.4.3.LATEST
is already installed in the org ?
For the RELEASED
keyword, I think this was just not existing when we wrote this command, so it needs to be added, I'll flag this as an enhancement.
Are you saying that if your
sfdx-project.json
file reference a version1.3.3.LATEST
it will install it even if a version1.4.3.LATEST
is already installed in the org ?
Yes, this is correct.
Well then I think it's working as designed, as the command is supposed to reflect what's in your dependency tree. Why not update your sfdx-project.json
with the correct dependency ?
I was expecting that using LATEST
or RELEASED
keyword will check if any of latest dependency versions are installed. Well it does, but on build level. May be LATEST
keyword can be applied on minor and major somehow - I'm just not aware. I would appreciate if you advice.
One problem that I see is that you may forgot to change dependency version in sfdx-project.json
. Plugin will install the older version that may cause other packages fail or fail processes around this dependent package.
Also we have several teams that develop packages using same dependency, and forcing them to follow for latest releases may cause some head blown ups 😄
There may be more, but I came with this one yet.
I do agree this is not ideal but that's the way Salesforce made it regarding the LATEST
keyword. That's the same version that is used to build a new package from this project.
So if you don't update your sfdx-project.json
, your new Unlocked Package (depending on the version listed under dependencies
) would also be based on the wrong version.
If you want to have more dynamic installs between several projects, you should have a look the sfpowerscripts orchestrator which may be doing what you want.
So if you don't update your sfdx-project.json, your new Unlocked Package (depending on the version listed under dependencies) would also be based on the wrong version.
Could not agree with that. Salesforce has no restrictions on dependencies when installing using sfdx force:package:install
or via UI. It's just installing if dependent package is installed (again, never tried with major version difference)
May be plugin can have something like --package
parameter that will just check if dependent package installed, but not installing version that provided in sfdx-project.json
I will review sfpowerscripts orchestrator
, thanks for advice. But I was hoping that when I use plugin, my headache is taken by this plugin and everything is working with one button. Don't really want to implement complicated logic, in this case plugin is no use for me.
Could not agree with that. Salesforce has no restrictions on dependencies when installing using sfdx force:package:install or via UI. It's just installing if dependent package is installed (again, never tried with major version difference)
I was talking about sfdx force:package:version:create
and not sfdx force:package:install
.
If you were to create a package version for a project depending on 1.3.3.LATEST
it would use the latest 1.3.3 version, and not pick the 1.4.3 version even if it exists. What I was saying is that there is no way to use something like 1.3.LATEST
, which would be what you want.
What you are basically requesting is either to use 1.3.LATEST
(not something Salesforce provides), or saying "I wrote 1.3.3
but I don't want why I wrote, I want 1.4.3
".
I agree that's not convenient for your use case but we are just following what Salesforce provides regarding the LATEST
keyword and the way to write dependencies in the sfdx-project.json
file.
Didn't understand this one
If you were to create a package version for a project depending on 1.3.3.LATEST it would use the latest 1.3.3 version, and not pick the 1.4.3 version even if it exists.
We can't install several versions of packages in Salesforce, only one. You saying that if in sfdx-package.json
provided dependency version 1.3.3.LATEST
Salesforce will use code from version provided even if newer version is installed? Sounds strange for me. Let me do some experiments.
What you are basically requesting is either to use 1.3.LATEST (not something Salesforce provides), or saying "I wrote 1.3.3 but I don't want why I wrote, I want 1.4.3".
This is not clear understanding. I want to use latest available version, or latest available version starting from major version 1. And just not think about it when creating my packages. In case when I'm providing strict version number like 1.2.3
, I'm expecting error throw if this version is not installed in org.
I understand, you want to use the latest available version. What I say, is that there is no way to specify this in in the sfdx-project.json
.
If you look at the doc, all the keywords like LATEST
are only available at the build level:
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_config_keywords.htm
Then you can still manually install whatever version you want, but when we talk about sfdx-project.json
, you'll have to specify a given version, beside the build number.
That is understandable and I'm not arguing over standard Salesforce functionality and features. But should plugins expand and simplify standard feature usage?
It may, I guess that's what sfpowerscripts orchestrator
is doing.
But this specific command is just about installing all packages dependencies just as described in your sfdx-project.json
.
Why ? Well let's say that you have a package A
, and a package B
depending on it.
Let's say package A
version 1.0.0
has a class named MyClass
, and package B
relies on it in its own code.
Package A
may be updated to version 1.1.0
with maybe some refactoring, where MyClass
would be deleted. Then if the command was automatically taking the latest release (1.1.0
) instead of the one listed under dependencies (1.0.0
), then your build would be broken until you fix the use of the missing class.
But your new version 1.1.0
may still be under development and not ready for prime time, so why use it absolutely ? Maybe you're just testing stuff, and until it's promoted you can still change your mind and reverse some changes. If you always take the latest version instead of the one listed, you would have no way to install the previous version you want, whereas the other way round you still can update the dependency version in your sfdx-project.json
file.
Let me be honest, I wish there would be a way to use something like 1.LATEST
, but unfortunately there is not.
The goal of this command is just, whether you have 1 or 10 dependencies in your file, you don't have to run 10 times the force:package:install command, but only one that will dynamically parse your sfdx-project.json
, get the number of packages and package ids and install them.
So I do understand that there is a need for what you ask, but I think it's outside of this command's scope.
Still, the code is open source so you can create your own command from it if sfpowerscripts orchestrator
isn't also doing what you want.
I'll keep this issue open because still, RELEASED
keyword should work, thanks for letting me know.
Sure, got your point. Sad to read that, but thanks.
Thank you for your communication.
Hi.
I'm playing around with SF packages CI/CD and some of packages contains dependencies to other packages.
How to properly provide latest version in
sfdx-project.json
sosfdx texei:package:dependencies:install
would install it correctly? For now it will install older version even if latest version is installed already.sfdx texei:package:dependencies:install
Package dependencies found for package directory force-app 04t3Y000001QpjJQAS : PackageName 1.4.3.LATEST Resolving dependencies... Done.
Installing package 04t3Y000001QpjJQAS : PackageName 1.4.3.LATEST
...
{ ... "dependencies": [ { "package": "PackageName", "versionNumber": "1.3.3.LATEST" } ] ... }
Package dependencies found for package directory force-app 04t3Y0000011MwvQAE : PackageName 1.3.3.LATEST Resolving dependencies... Done.
Installing package 04t3Y0000011MwvQAE : PackageName 1.3.3.LATEST ...