Skip to content

Commit 785e9a9

Browse files
Xiaoyi ChenekapnerlcamposLisandroFernandezSF
authored
Release/v49.9.1 (#217)
* Update contribution guide (#190) * add coding and commit guidelines, start developing doc * update contributing docs * update develop doc, update launch config * Update CONTRIBUTING.md * Update README.md * Update coding-guidelines.md * Update commit-guidelines.md * Update developing.md * Update CONTRIBUTING.md Co-authored-by: Xiaoyi Chen <xchen@salesforce.com> * Update commit-guidelines.md * Update developing.md * Update developing.md * update contributing docs * Update developing.md Co-authored-by: Emily Kapner <ekapner@salesforce.com> * port #186 (#199) * Update dev scripts (#200) @W-8017763@ * Remove @salesforce/templates from yarn.lock (#201) @W-8017763@ * Lf/new functions template (#205) * Adding Functions template * Adding test for the new template * Removing unnecessary lines and spaces * Adding Functions template * Adding test for the new template * Removing unnecessary lines and spaces * Removing unnecessary type and tslint line * Removing unnecessary type * Update packages/templates/src/templates/project/functions/ScratchDef.json There is a specific scratch org feature for functions. Co-authored-by: lcampos <lcamposguajardo@gmail.com> * I remove code that affects the plugin * empty commit Co-authored-by: lcampos <lcamposguajardo@gmail.com> Co-authored-by: Emily Kapner <ekapner@salesforce.com> Co-authored-by: lcampos <lcamposguajardo@gmail.com> Co-authored-by: Lisandro Fernandez <70181900+LisandroFernandezSF@users.noreply.github.com>
1 parent 42343cd commit 785e9a9

File tree

20 files changed

+377
-145
lines changed

20 files changed

+377
-145
lines changed

.circleci/config.yml

+3
Original file line numberDiff line numberDiff line change
@@ -79,6 +79,9 @@ jobs:
7979
- run:
8080
name: Build plugin
8181
command: yarn build
82+
- run:
83+
name: Lint source files
84+
command: yarn lint
8285
- run:
8386
name: Testing
8487
command: yarn test

.vscode/launch.json

+3-10
Original file line numberDiff line numberDiff line change
@@ -15,16 +15,9 @@
1515
"name": "Run All Tests",
1616
"type": "node",
1717
"request": "launch",
18-
"protocol": "inspector",
19-
"program": "${workspaceFolder}/packages/plugin-templates/node_modules/mocha/bin/_mocha",
20-
"args": ["--inspect", "--no-timeouts", "--colors", "test/**/*.test.ts"],
21-
"env": {
22-
"NODE_ENV": "development",
23-
"SFDX_ENV": "development"
24-
},
25-
"sourceMaps": true,
26-
"smartStep": true,
27-
"internalConsoleOptions": "openOnSessionStart",
18+
"cwd": "${workspaceFolder}",
19+
"runtimeExecutable": "yarn",
20+
"runtimeArgs": ["test"],
2821
"preLaunchTask": "Compile"
2922
},
3023
{

CONTRIBUTING.md

+25
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
## Contributing
2+
3+
1. Familiarize yourself with the codebase by reading the [docs](docs), in
4+
particular the [development](contributing/developing.md) doc.
5+
1. Create a new issue before starting your project so that we can keep track of
6+
what you're trying to add/fix. That way, we can also offer suggestions or
7+
let you know if there is already an effort in progress.
8+
1. Fork this repository.
9+
1. The [development](contributing/developing.md) doc has details on how to set up your environment.
10+
1. Create a _topic_ branch in your fork based on the correct branch (usually the **develop** branch, see [Branches section](#branches)). Note: this step is recommended but technically not required if contributing using a fork.
11+
1. Edit the code in your fork.
12+
1. Sign CLA (see [CLA](#cla).
13+
1. Send us a pull request when you're done. We'll review your code, suggest any
14+
needed changes, and merge it in.
15+
16+
## Pull Requests
17+
18+
### CLA
19+
20+
External contributors are required to sign a Contributor's License
21+
Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.
22+
23+
### Merging Pull Requests
24+
25+
- Pull request merging is restricted to squash and merge only.

README.md

+8-62
Original file line numberDiff line numberDiff line change
@@ -1,75 +1,21 @@
11
# salesforcedx-templates
22

3-
This repository provides a series of commands, templates, and generators for various metadata types. It is bundled with the [salesforcedx plugin](https://www.npmjs.com/package/salesforcedx).
4-
53
[![CircleCI](https://circleci.com/gh/forcedotcom/salesforcedx-templates/tree/master.svg?style=shield)](https://circleci.com/gh/forcedotcom/salesforcedx-templates/tree/master)
64
[![Codecov](https://codecov.io/gh/forcedotcom/salesforcedx-templates/branch/master/graph/badge.svg)](https://codecov.io/gh/forcedotcom/salesforcedx-templates)
75
[![Known Vulnerabilities](https://snyk.io/test/github/forcedotcom/salesforcedx-templates/badge.svg)](https://snyk.io/test/github/forcedotcom/salesforcedx-templates)
86
[![License](https://img.shields.io/npm/l/salesforcedx-templates.svg)](https://github.com/forcedotcom/salesforcedx-templates/blob/master/package.json)
97

10-
## Getting Started
11-
12-
To use, install the [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli) and run the following commands.
13-
14-
```
15-
Verify the CLI is installed
16-
$ sfdx (-v | --version)
17-
Install the salesforcedx plugin
18-
$ sfdx plugins:install salesforcedx
19-
To run a command
20-
$ sfdx [command]
21-
```
22-
23-
To build the plugin locally, make sure to have yarn installed and run the following commands:
24-
25-
```
26-
Clone the repository
27-
$ git clone git@github.com:forcedotcom/salesforcedx-templates.git
28-
Install the dependencies and compile
29-
$ yarn install
30-
$ yarn build
31-
Link your plugin to the sfdx cli
32-
$ sfdx plugins:link .
33-
To verify
34-
$ sfdx plugins
35-
salesforcedx-templates 0.0.0 (link) /Users/a.jha/Documents/repos/salesforcedx-templates
36-
```
8+
## Introduction
379

38-
## Commands
10+
This repository provides:
3911

40-
- [`sfdx force:apex:class:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forceapexclasscreate)
41-
- [`sfdx force:apex:trigger:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forceapextriggercreate)
42-
- [`sfdx force:lightning:app:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcelightningappcreate)
43-
- [`sfdx force:lightning:component:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcelightningcomponentcreate)
44-
- [`sfdx force:lightning:event:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcelightningeventcreate)
45-
- [`sfdx force:lightning:interface:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcelightninginterfacecreate)
46-
- [`sfdx force:lightning:test:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcelightningtestcreate)
47-
- [`sfdx force:project:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forceprojectcreate)
48-
- [`sfdx force:visualforce:component:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcevisualforcecomponentcreate)
49-
- [`sfdx force:visualforce:page:create`](https://github.com/forcedotcom/salesforcedx-templates/blob/master/COMMANDS.md#sfdx-forcevisualforcepagecreate)
12+
- [@salesforce/plugin-templates](https://www.npmjs.com/package/@salesforce/plugin-templates): oclif plugin that supports a series of commands, templates, and generators for various metadata types. It is bundled with the [salesforcedx plugin](https://www.npmjs.com/package/salesforcedx).
13+
- [@salesforce/templates](https://www.npmjs.com/package/@salesforce/templates) to support the plugin and [Salesforce VS Code extensions](https://github.com/forcedotcom/salesforcedx-vscode/).
5014

51-
## Debugging your plugin
52-
53-
We recommend using the Visual Studio Code (VS Code) IDE for your plugin development. Included in the `.vscode` directory of this plugin is a `launch.json` config file, which allows you to attach a debugger to the node process when running your commands.
54-
55-
To debug the `hello:org` command:
56-
57-
If you linked your plugin to the sfdx cli, call your command with the `dev-suspend` switch:
58-
59-
```sh-session
60-
$ sfdx hello:org -u myOrg@example.com --dev-suspend
61-
```
15+
## Getting Started
6216

63-
Alternatively, to call your command using the `bin/run` script, set the `NODE_OPTIONS` environment variable to `--inspect-brk` when starting the debugger:
17+
If you're interested in contributing, take a look at the [CONTRIBUTING](CONTRIBUTING.md) guide.
6418

65-
```sh-session
66-
$ NODE_OPTIONS=--inspect-brk bin/run hello:org -u myOrg@example.com
67-
```
19+
If you're interested in building the plugin and library locally, take a look at the development [doc](contributing/developing.md).
6820

69-
2. Set some breakpoints in your command code
70-
3. Click on the Debug icon in the Activity Bar on the side of VS Code to open up the Debug view.
71-
4. In the upper left hand corner of VS Code, verify that the "Attach to Remote" launch configuration has been chosen.
72-
5. Hit the green play button to the left of the "Attach to Remote" launch configuration window. The debugger should now be suspended on the first line of the program.
73-
6. Hit the green play button at the top middle of VS Code (this play button will be to the right of the play button that you clicked in step #5).
74-
<br><img src=".images/vscodeScreenshot.png" width="480" height="278"><br>
75-
Congrats, you are debugging!
21+
You can find more information about commands that the plugin provide in the [commands](COMMAND.md) doc.

contributing/coding-guidelines.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# Coding Guidelines
2+
3+
When possible, the following are enforced through the code formatter
4+
(Prettier.js) and tslint rules.
5+
6+
---
7+
8+
## Indentation
9+
10+
We use spaces, not tabs.
11+
12+
## Names
13+
14+
- Use PascalCase for `type` names
15+
- Use UPPERCASE_WITH_SPACES for `enum` values and constants
16+
- Use camelCase for `function` and `method` names
17+
- Use camelCase for `property` names and `local variables`
18+
- Use whole words in names when possible
19+
- Use camelCase for file names (name files after the main Type it exports)
20+
21+
## Conventions
22+
23+
- Create a folder for each major sub-area
24+
- In the folder, create an `index.ts` that exports the public-facing API for that
25+
sub-area.
26+
- Tests can refer directly to the `.ts` files; other consumers should refer to the
27+
`index.ts` file.
28+
29+
## Comments
30+
31+
- Use comments sparingly because comments always become outdated quickly.
32+
- If you must, use JSDoc style comments.
33+
34+
## Strings
35+
36+
- Use 'single quotes'
37+
- All strings visible to the user need to be externalized in a `messages.ts` file.
38+
39+
## null and undefined
40+
41+
Use `undefined`, do not use `null`.

contributing/commit-guidelines.md

+63
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
# Commit Guidelines
2+
3+
When working on a large project with multiple users, it's a good idea to follow
4+
a convention for committing in Git. A guide that we follow is
5+
https://chris.beams.io/posts/git-commit/. The purpose of this document is not to
6+
be nitpicky – instead, the goal is to help provide some guidelines on what is a
7+
good commit message. These guidelines are general, and apply to most projects
8+
that use Git.
9+
10+
Here's a summary:
11+
12+
- Separate subject from body with a blank line
13+
- Limit the subject line to 50 characters (this is a guide but not strictly
14+
enforced)
15+
- Capitalize the subject line
16+
- Do not end the subject line with a period
17+
- Use the imperative mood in the subject line
18+
- <strike>Wrap the body at 72 characters</strike> (this is not strictly
19+
enforced)
20+
- Use the body to explain what and why vs. how
21+
- Don't use internal bug numbers because you might run out of characters
22+
- The commit log is _not_ a diary - keep it short and relevant to the project,
23+
not to what a developer is thinking at that moment. Longer discussions can be
24+
had in the PRs.
25+
- Because we use squash and merge, ensure that the final squashed commit message
26+
makes sense.
27+
- No WIP markers in the subject
28+
- No DO-NOT-MERGE markers in the subject
29+
- No MyName/branchname in the subject
30+
31+
Here's an example of a good and easy-to-read commit log that shows only the subject
32+
(slightly modified from our git log output)
33+
34+
```
35+
* 8d6a286 - (HEAD -> develop) Fix capitalization of package display name (#466) (3 weeks ago) <Ruth Sears-Blazej>
36+
* 96cb255 - Added feature request template (#462) (3 weeks ago) <Nathan Totten>
37+
* 8da30f8 - Introduce salesforcedx-webview-ui package (#451) (3 weeks ago) <Nick Chen>
38+
* 57abc05 - Add an event listener for changes to the sfdx-config file (#457) (3 weeks ago) <Allison Leong>
39+
* 5d5d7dc - Mark apex replay debugger as preview (#458) (3 weeks ago) <Nick Chen>
40+
* 8ace1d7 - Bump lwc-language-server to 1.5.1 (#456) (3 weeks ago) <Nick Chen>
41+
* fb7dda1 - Remove note about limitations of Live Share (#455) (3 weeks ago) <Nick Chen>
42+
* d07a21b - Send initialized event when logcontext is ready (#454) (4 weeks ago) <Jonathan Widjaja>
43+
* 42aaddd - Turn off logging will delete the traceflag (#437) (4 weeks ago) <James Sweetman>
44+
* 9adfcbb - Update UI Text (#453) (4 weeks ago) <JimSuplizio>
45+
* e0a0b7d - Bump vscode dependency to 1.23 (#452) (4 weeks ago) <Nick Chen>
46+
* 27c4bec - Make lwc-next the current version of lwc (#450) (4 weeks ago) <Nick Chen>
47+
* cc0afd8 - Add ISV debugger docs (#414) (4 weeks ago) <Ruth Sears-Blazej>
48+
* 8dc4b75 - Merge branch 'release/v42.18.0' into develop (4 weeks ago) <Nick Chen>
49+
...
50+
```
51+
52+
Here's an example of a good and easy-to-read commit message (after everything has been squashed)
53+
54+
```
55+
Ignore warnings and CLI update messages when using --json (#406)
56+
57+
* Ignore warnings and CLI update messages when using --json
58+
* Remove integration tests for setting eslint
59+
* Clean up npm lint
60+
* Remove test from vscode-lwc as well
61+
62+
@W-4485495@
63+
```

contributing/developing.md

+126
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,126 @@
1+
# Developing
2+
3+
## Get Started
4+
5+
1. Clone the repository, and `cd` into it.
6+
7+
```sh
8+
git clone git@github.com:forcedotcom/salesforcedx-templates.git
9+
```
10+
11+
2. Ensure you have [Yarn](https://yarnpkg.com/) installed and run the following to build:
12+
13+
```
14+
yarn install
15+
yarn build
16+
```
17+
18+
## Branches
19+
20+
- We work in `develop`.
21+
- Our released (aka. _production_) branch is `main`.
22+
- Our work happens in _topic_ branches (feature and/or bug-fix).
23+
- feature as well as bug-fix branches are based on `develop`
24+
- _Topic_ branches can live in forks (external contributors) or within this repository (committers).
25+
\*\* When creating _topic_ branches in this repository please prefix with `<developer-name>/`.
26+
- branches _should_ be kept up-to-date using `rebase`
27+
- see below for further merge instructions
28+
29+
### Merging between branches
30+
31+
- We try to limit merge commits as much as possible.
32+
33+
- They are usually only ok when done by our release automation.
34+
35+
- _Topic_ branches are:
36+
37+
1. based on `develop` and will be
38+
1. squash-merged into `develop`.
39+
40+
- Hot-fix branches are an exception.
41+
- Instead we aim for faster cycles and a generally stable `develop` branch.
42+
43+
### Merging `develop` into `main`
44+
45+
- When a development cycle finishes, the content of the `develop` branch will become the `main` branch
46+
47+
```
48+
$ git checkout main
49+
$ git reset --hard develop
50+
$
51+
$ # Using a custom commit message for the merge below
52+
$ git merge -m 'Merge -s our (where _ours_ is develop) releasing stream x.y.z.' -s ours origin/main
53+
$ git push origin main
54+
```
55+
56+
### Making Pull Requests
57+
58+
Take a look at [CONTRIBUTING](../CONTRIBUTING.md) doc for making and merging pull requests.
59+
60+
## Developing Plugin
61+
62+
To test plugin locally, use `bin/run` in place of `sfdx`. For example:
63+
64+
```sh
65+
./bin/run force:apex:class:create --classname 'TestClass' --template 'DefaultApexClass' --outputdir ./testsoutput/myApex/
66+
```
67+
68+
To test plugin locally with Salesforce CLI, add `"@salesforce/templates": "file://path/to/packages/templates"` to the plugin's `package.json`.
69+
70+
Link your plugin to Salesforce CLI:
71+
72+
```sh
73+
sfdx plugins:link .
74+
```
75+
76+
Verify plugin is linked:
77+
78+
```sh
79+
sfdx plugins
80+
```
81+
82+
### Debugging Your Plugin
83+
84+
We recommend using the Visual Studio Code (VS Code) IDE for your plugin development. Included in the `.vscode` directory of this plugin is a `launch.json` config file, which allows you to attach a debugger to the node process when running your commands.
85+
86+
To debug the `hello:org` command:
87+
88+
1. If you linked your plugin to the Salesforce CLI, call your command with the `dev-suspend` switch:
89+
90+
```sh-session
91+
$ sfdx hello:org -u myOrg@example.com --dev-suspend
92+
```
93+
94+
Alternatively, to call your command using the `bin/run` script, set the `NODE_OPTIONS` environment variable to `--inspect-brk` when starting the debugger:
95+
96+
```sh-session
97+
$ NODE_OPTIONS=--inspect-brk bin/run hello:org -u myOrg@example.com
98+
```
99+
100+
2. Set some breakpoints in your command code.
101+
3. Click on the Debug icon in the Activity Bar on the side of VS Code to open up the Debug view.
102+
4. In the upper left hand corner of VS Code, verify that the "Attach to Remote" launch configuration is selected.
103+
5. Hit the green play button to the left of the "Attach to Remote" launch configuration window. The debugger should now be suspended on the first line of the program.
104+
6. Hit the green play button at the top middle of VS Code (this play button is to the right of the play button that you clicked in step #5).
105+
<br><img src="../.images/vscodeScreenshot.png" width="480" height="278"><br>
106+
Congrats, you are debugging!
107+
108+
## Developing Library
109+
110+
Adding a new template:
111+
112+
1. Define a new template type in `TemplateType`, and add available template options extending `TemplateOptions` in library [types](../packages/templates/src/utils/types.ts).
113+
2. Create a generator extending [`SfdxGenerator`](../packages/templates/src/generators/sfdxGenerator.ts) in [generators](../packages/templates/src/generators) folder. Take a look at [`ApexClassGenerator`](../packages/templates/src/generators/apexClassGenerator.ts) for an example.
114+
115+
- Generator class file should default export a generator class extending `SfdxGenerator`
116+
- Generator class file should have a name same as the template type's name, except with the first letter lowercased
117+
118+
## Testing
119+
120+
Run the following to test library and plugin:
121+
122+
```sh
123+
yarn test
124+
```
125+
126+
If you are using VS Code for development, the following launch configurations are available: "Run All Tests", "Run Current Test", "Run Current Test Without Compile". Have `"debug.javascript.usePreview": true` in your user setting enabled so you can utilize [`vscode-js-debug`](https://github.com/microsoft/vscode-js-debug) debugger. This setting is enabled by default in VS Code version 1.47.

lerna.json

+1-3
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,5 @@
11
{
22
"version": "49.9.0",
33
"npmClient": "yarn",
4-
"packages": [
5-
"packages/*"
6-
]
4+
"packages": ["packages/*"]
75
}

0 commit comments

Comments
 (0)