[7.186.2] Language bug upon package version creation when installing dependencies with validation skipped

[petter-eikeland]

Summary

When trying to create a new package version, if the dependent package was created without validation, then language errors might occur. Might be related to previous issue #1883

Steps To Reproduce:

Repository to reproduce: dreamhouse-lwc

1. Ensure that you are connected to a DevHub with a default language != English (or language on user is != English, not sure how default language is set in build orgs). In my case this is Norwegian. Also ensure that the language option in project-scratch-def.json is set to en_US:
   "language": "en_US",

2. Create new folder archive and add a custom object Archive__c with the Vowel parameter in the object file:
   <startsWith>Vowel</startsWith>

3. Create a new package using sfdx package create -n archive -r archive -t Unlocked -v myhuborg

4. Successfully create new version of archive package using sfdx package version create -p archive -w 10 -x -v myhuborg -f config/project-scratch-def.json --skip-validation
   NB! This is created without validation

5. Create second folder archive-field. Add Archive field "Test_Field__c"

6. Create second package using sfdx package create -n archive-field -r archive-field -t Unlocked -v myhuborg

7. Add archive package as dependency to archive-field package

8. Create version of archive-field package using sfdx package version create -p archive-field -w 15 -x -v myhuborg -f config/project-scratch-def.json

Expected result

A new package version of archive-field is successfully created

Actual result

Error (1): Multiple errors occurred:
(1) Det oppstod en feil ved forsøk på å installere en pakkeavhengighet. ID 04t090000003oVs: Archive__c: Cannot specify a startsWith attribute for this language

System Information

{
  "cliVersion": "sfdx-cli/7.186.2",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v18.13.0",
  "pluginVersions": [
    "@dxatscale/sfpowerscripts 20.2.11 (user)",
    "@eon-com/eon-sfdx 1.9.4 (user)",
    "@oclif/plugin-autocomplete 1.4.2 (core)",
    "@oclif/plugin-commands 2.2.4 (core)",
    "@oclif/plugin-help 5.2.1 (core)",
    "@oclif/plugin-not-found 2.3.17 (core)",
    "@oclif/plugin-plugins 2.2.4 (core)",
    "@oclif/plugin-search 0.0.11 (core)",
    "@oclif/plugin-update 3.1.0 (core)",
    "@oclif/plugin-version 1.2.1 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.23 (core)",
    "@oclif/plugin-which 2.2.9 (core)",
    "1commerce 0.0.10 (user)",
    "alias 2.1.19 (core)",
    "apex 1.4.3 (core)",
    "auth 2.3.12 (core)",
    "community 2.1.5 (core)",
    "config 1.4.23 (core)",
    "custom-metadata 2.0.16 (core)",
    "data 2.1.22 (core)",
    "generator 2.0.17 (core)",
    "info 2.3.5 (core)",
    "limits 2.2.3 (core)",
    "org 2.2.24 (core)",
    "packaging 1.12.4 (core)",
    "schema 2.2.3 (core)",
    "signups 1.2.12 (core)",
    "source 2.3.16 (core)",
    "telemetry 2.0.7 (core)",
    "templates 55.2.3 (core)",
    "trust 2.3.0 (core)",
    "user 2.2.1 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "salesforce-alm 54.8.5 (core)",
    "sfdmu 4.26.2 (user)",
    "sfpowerkit 6.0.1 (user)"
  ],
  "osVersion": "Darwin 21.6.0",
  "shell": "zsh",
  "rootPath": "/Users/user/.local/share/sfdx/client/7.186.2-b2fe485"
}

Additional information

This error does not occur when downgrading sfdx version to 7.179.0. However, after creating a new package version on 7.179.0 with validation skipped, installing 7.186.2 and creating a new version of archive-fields --> the bug occurs again

If the archive package is created with validation, then the bug does not occur

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[git2gus]

This issue has been linked to a new work item: W-12513253

[JorisOldeBijvank]

Hello, does anybody know of any known workaround to address this problem?

[petter-eikeland]

@JorisOldeBijvank If I remember correctly I do not get this error when the latest package dependency was created with validation. We have just downgraded our CLI versions to below 7.186 until it is resolved

I have an ongoing case with Salesforce Support regarding this, they have been trying to recreate the bug for some time

[JorisOldeBijvank]

@petter-eikeland Thank you for your comment.

Unfortunately, downgrading our CLI version causes problems with the new naming conventions of Global Value Sets.

I have to keep my fingers crossed until it is resolved, and in the meantime, I will try to deploy the source directly to the org without a package and see if that'll work.

[petter-eikeland]

@JorisOldeBijvank They were able to replicate the issue just now:

[petter-eikeland]

@JorisOldeBijvank Seems like the newest RC contains a fix, have not tested it yet

[JorisOldeBijvank]

Ah, great. Thanks for letting me know!

[petter-eikeland]

Seems like this is fixed with the newest RC!

Feel free to close