Link dependencies as SFDX packages

[dangmai]

In order to make use of dependency management, we have to link dependencies as SFDX 2nd-generation packages, so that they are deployed to scratch orgs together with our own custom code.

[dangmai]

Dependencies are now installed/deduped/linked from the main project.

However, the format of the charge config needs to be figured out. Some obstacles we're running into:

• Somehow we need to make sure dependencies don't list their own dependencies in sfdx-project.json
• Making use of 2nd generation packaging
• Removing packages after dependency is uninstalled

[dangmai]

Based on the Dreamforce videos, it looks like Salesforce already has a way to define dependencies in the sfdx-project.json file. We should use that instead of appening directly to packageDirectories.

Here's what I have in mind:

• By default, it'll use the package id that the package comes with unless specified otherwise. This means it'll be a managed package.
• If the package does not have an id, or if the user so chooses, they have 2 options:
  • Locked package
  • Unlocked package
• These 2 options may be changed by editing the sfdx-project.json file.

So, the default chain is: package id (if present) -> locked (if package id not present) -> unlocked (only happens if specified).

This should be applied at the end user level, i.e. preferences by a dependency will be ignored once that dependency is installed by the end user.

For libraries, it's necessary that we enforce 1 package directory per library, since sfdx does not have a name associated with each package directory. By convention, we'll name the package directory to be the same as the package name.

[dangmai]

After thinking about this more, I'm not sure including managed packages would be the best idea anymore. Managed packages are basically black boxes that are upgrade-able but really difficult to downgrade, so moving to an old version (for example, if a dependency uses a <= for dependency version) would be next to impossible.

Right now it makes more sense for me to only support locked and unlocked packages with Charge; after all, the user can still put in a manual dependency on managed package in the sfdx-package.json file.

With managed packages out of the way, the flow would be:

• By default, it'll ignore whichever package id that comes with dependencies.
• Dependencies will be, by default, locked, unless the user changes it to be unlocked.

At the time of npm install, we can put in a hook to automatically create a package on to the target Dev Hub, as well as install the particular version on to the scratch org.