One-time Setup
Quick Start
Testing
Debugging
Linking to the Packaging Plugin
TypeScript Module Conflicts
Useful Yarn Commands
- Install NodeJS. If you need to work with multiple versions of Node, you
might consider using nvm.
Suggestion: use the current LTS version of node. - Install yarn to manage node dependencies.
Suggestion: install yarn globally usingnpm install --global yarn
- Clone this repository from git. E.g., (ssh):
git clone [email protected]:forcedotcom/packaging.git
- Configure git commit signing.
cd
into thepackaging
directory- Checkout the main branch:
git checkout main
- Get all latest changes:
git pull
- Download NPM dependencies:
yarn install
. If it's been a while since you last did this you may want to runyarn clean-all
before this step. - Build and lint the code:
yarn build
- Create a branch off main for new work:
git checkout -b <branch_name>
Suggestion: use branch_name format of initials/work-title. For external contributors, please fork the main branch of the repo instead and PR the fork to the main branch. - Make code changes and build:
yarn build
- Write tests and run:
yarn test
(unit) and/oryarn test:nuts
(NUTs) - Show all changed files:
git status
- Add all files to staging:
git add .
- Commit staged files with helpful commit message:
git commit
. New features should prepend the commit message with "feat:". Bug fixes should prepend, "fix:". - Push commit(s) to remote:
git push -u origin <branch_name>
- Create a pull request (PR) using the GitHub UI here.
All changes must have associated tests. This library uses a combination of unit testing and NUTs (non-unit tests). You can also manually test the library using the REPL script.
To manually test your changes you can simply run yarn repl
and send input to any of the 4 main library classes; Package
, PackageVersion
, SubscriberPackageVersion
, and Package1Version
. "REPL" is an acronym for Read-Evaluate-Print-Loop, and provides a convenient way to quickly test JavaScript code. Most methods on the 4 classes require at least an org Connection
so use the getConnection(username)
function and pass the username or alias of an existing, CLI-authed target org. If the API you're calling also requires a DX project, get an instance of SfProject
to use in the REPL by providing the absolute path to your project directory.
The REPL script also starts a debugger process you can attach to with your preferred editor. See the Debugging section for details of how to attach to the REPL debugger process.
Unit tests are run with yarn test
and use the mocha test framework. Tests are located in the test directory and are named with the pattern, <test-file>.test.ts
. E.g., package.test.ts. Reference the existing unit tests when writing and testing code changes.
Non-unit tests are run with yarn test:nuts
and use the cli-plugin-testkit framework. These tests run using the default devhub in your environment and the test project located in test/package/resources/packageProject
. This is a way to test the library code in a real environment versus a unit test environment where many things are stubbed.
If you need to debug library code or tests you should refer to the excellent documentation on this topic in the Plugin Developer Guide. It may be easiest to use the REPL script with your debugger.
When you want to use a branch of this repo in the packaging plugin to test changes, follow these steps:
- With the library changes built (e.g.,
yarn build
), link the library by runningyarn link
. cd
toplugin-packaging
and runyarn clean-all
.- Download NPM dependencies:
yarn install
. - Use the linked packaging library:
yarn link "@salesforce/packaging"
. - Build and lint the code:
yarn build
. If you get TypeScript module conflict errors during this step, see section below on TypeScript module conflicts.
During TypeScript compilation, you may see errors such as:
error TS2322: Type 'import(".../plugin-packaging/node_modules/@salesforce/core/lib/org/connection").Connection' is not assignable to type 'import(".../packaging/node_modules/@salesforce/core/lib/org/connection").Connection'.
This means the Connection
interface in the core library used by the packaging plugin is different from the Connection
interface in the core library used by the packaging library, most likely because the core library dependencies are different versions.
To fix this we need to tell the TypeScript compiler to use 1 version of that library. To do this, temporarily modify the tsconfig.json file with the following lines inside the compilerOptions
section and recompile:
"baseUrl": ".",
"paths": {
"@salesforce/core": ["node_modules/@salesforce/core"]
}
If there are conflict errors in the tests then we need to make a similar modification to the test/tsconfig.json file. Note that the baseUrl
property for this modification points to the directory above:
"baseUrl": "..",
"paths": {
"@salesforce/core": ["node_modules/@salesforce/core"]
}
Note that these are temporary changes for linked compilation and should not be committed.
This downloads all NPM dependencies into the node_modules directory.
This compiles the typescript to javascript.
This lints all the typescript using eslint.
This compiles and lints all the typescript (e.g., yarn compile && yarn lint
).
This cleans all generated files and directories. Run yarn clean-all
to also clean up the node_module directories.
This runs unit tests (mocha) for the project using ts-node.
This runs NUTs (non-unit tests) for the project using ts-node.