Salesforce Lightning CLI

Salesforce Lightning CLI

The Salesforce Lightning CLI is a linting tool that allows developers to check if their codebase has problematic code in its JavaScript. In addition to common lint checks, it scans the code for access and LockerService issues and reports on them. Developers should be able to use this tool to ensure that they write secure code that will not fail the checks done by the framework or LockerService when the component is being used. To get a better understanding of the Salesforce Lightning CLI, I ran it against a Lightning Component that I created a while ago. This post details my experience learning about the Salesforce Lightning CLI tool.

The Component

I created a file upload Lightning Component to teach myself more about the capabilities and APIs of Lightning Components a little more than a year and a half ago. A while later, I created an unmanaged package of it to learn more about the packaging of Lightning Components. The source is available on github.

Background

The Salesforce Lightning CLI can be installed following the directions in the Lightning Components Developer Guide or npm page. It relies on the Heroku Toolbelt, so that must be installed first. After you run the installation command you can verify that it installed by running the heroku plugins command and seeing it as one of the installed plugins.

Using the Salesforce Lightning CLI

My first run was on all of the Lightning source code, which the tool limits to the JavaScript files.

There were a few errors (I’ll get to those later) and warnings. Most of the warnings were “Trailing spaces not allowed”. That would be easy enough to quickly fix with a simple find and replace strategy, a change to IDE settings, etc., but I wanted to see if I could change the tool to ignore trailing white space as a warning.

The tool uses ESLint to perform the linting. You can see all of the configurations and rules for the tool in the subdirectories under ~/.heroku/node_modules/salesforce-lightning-cli/ and corresponding documentation in the LC Dev guide. By following the Custom “House Style” Rules directions, I was able to specify that I wanted the trailing whitespace to be ignored. The file ~/.heroku/node_modules/salesforce-lightning-cli/lib/code-style-rules.js shows the non-essential / stylish rules. I copied the code-style-rules.js to project-style-rules.js in the root project folder (sibling of src directory) and modified it to only have the following:

I ran the command again and specified the custom config file and got the desired result. The terminal outputs information about the custom rules so you know they are being used.

Alternatively, all warnings can be ignored by running it with the –quiet option.

Doing that narrowed the output down to three ‘Invalid Aura API’ errors for $A.util.isUndefined, $A.error, and $A.run.

The rules related to the aura APIs should match up to what is documented in your org’s auradocs at https://yourinstance.lightning.force.com/auradocs, but make sure to double check if an error is reported when you think it should not be. I did find that $A.util.isUndefined was reported as an error, even though it is documented in the auradocs.

One of the nice things is that since the tool uses ESLint, you can use some of its capabilities. For example, you can disable specific rules on a line-by-line or file-by-file basis. To disable the $A.util.isundefined from failing I added a comment to the source.

Be careful though. If you disable something that would fail the rule enforced by the Lightning runtime in Salesforce, you just don’t see the errors reported, but the component will still get the error when the offending code executes in its container.

The $A.error lint violation was because $A.error is deprecated and the recommendation now is to throw an instance of Error (e.g., throw new Error(msg)). The $A.run has been deprecated in favor of $A.getCallback(). The component didn’t really need either one of them, so I just deleted those lines.

I ran into another issue that caused the component to not work at all. When the LockerService was enabled the file input’s files array was undefined. There is a question on the Salesforce Stack Exchange about it.

More

The Salesforce Lightning CLI tool is a needed and very useful tool for Lightning Component development. I’m sure it will be used in other places such as hooking it in to CI and/or configuring it or calling it from grunt/gulp (that’s the beauty of a CLI!). Refer to the Lightning Components Developer Guide’s Salesforce Lightning CLI section for more information about the tool.