Setting up ESLint with Google Standards and Salesforce LWC standards in VSCode

If you are part of a team of developers and want to ensure coding standards, ESLint is one of the easiest and most reliable ways to do so. The problem is, ESLint can be a bit of a pain to get working right. I have outlined the steps you need to take in order to start enforcing your coding standards without having to remember when to type 2 spaces or 4! Because no one really wants to spend any extra keystrokes on typing extra spaces. If you are not doing Lightning Web Component development on the Salesforce platform, you can skip the LWC standards part of these steps.

Step One… from your command line, in your project root type the following:

>npm init (Accept the defaults as you are guided through the prompts)

Step Two….

>npm install eslint –save-dev (this will set ESLint to your local directory)

Step Three…

./node_modules/.bin/eslint –init

(follow instructions, selecting appropriately and finally selecting Google for style)

Step Four….

npm install eslint @salesforce/eslint-config-lwc –save-dev

Step Five…

In `.eslintrc.json` (in project root), paste the following:


  “extends”: [“@salesforce/eslint-config-lwc/recommended”,”google”]


If you are lucky and you don’t have a global install of the same modules, ESLint may be working perfectly for you at this point… e.g. your JS files now look like one giant error… yay!

If you are normal, and you have a mix of global and local ESLint installs going on, follow the next steps to clean up your project and make the angry ESLint error at the bottom of your screen go away….

*if ESLInt is throwing an error due to the module path not found, go to Preferences ==> Settings ==> Workspace ==> Extensions ==> ESLint ==> ESLint: Node Path 

Edit the file to point to your local config i.e. if it looks like this (global):

 “eslint.nodePath”: “homepath/.vscode/extensions/salesforce.salesforcedx-vscode-lwc-46.10.0/node_modules”,

Change it to the relative to your machine version of this:

“eslint.nodePath”: “homepath/git/myDirectory/force-app/main/default/lwc/.eslintrc.json”

Now make sure your file associations for JS files is set to use ESLint and auto format on save and you are off to the races!

For more information on the modules I am using here see:


Happy coding!

UI Developers really can design… even without HiFi mockups!

Our human minds love to put things into boxes. We strive to categorize, organize and streamline. In the development process, we have attempted to break the steps of creating software into “logical” parts as though the dev team where musicians in an orchestra that could be arranged in an ideal manner to best suit the conductor. Having been part of many teams where this categorization occurs, I can say safely that this approach is destined for disaster.

Why am I cynical about an approach that has thousands of books, articles, and manifestos touting its glory? I am cynical because in my own experience, categorizing people is a limiting approach to empowering creativity. I think as developers, there is an expectation that harkens back to the days of the mainframe computer that we are not interested in how things look nor should we have much by way of opinions about the matter. That is total hogwash. I am not alone, even if I may be unique, in being extremely aesthetically driven and opinionated as an engineer. Separating design from the front end development process is like separating taste from cooking or textiles from fashion. You just cannot do it and still have a cohesive product. At best you have introduced a layer of unnecessary bureaucracy.

This is not to say that we should not have flows which will determine the user experience or low fidelity mock ups which allow stake holders to grok what the product team is suggesting for a solution. What I am against, is the predetermining of every visual aspect of a feature by UX designers and then handing said blueprints off to the UI dev. What we have just done, is add a layer of complexity. A great, or even good, UI developer can take low rez. mock ups and given a set of UX patterns (already decided upon by the company or product team) rapidly build a working prototype that then can be handed back to the stakeholders for sign-off.

Why would you not do this? In our new process, we have now two steps to iterate upon rather than one. Here is how it goes in our divided system… HiFi mocks are iterated upon with product, UX designer, and stakeholders. Everyone is happy, UX designer hands mocks to UI developer. UI developer goes and churns out the feature to spec. hopefully everything makes sense from a programmatic standpoint. If it doesn’t make sense, UI dev has to reach out to UX designer who then reaches out to stakeholder/product for confirmation of change, UX designer iterates on their own design and hands it back to UI dev again. UI dev continues and when finished presents to stakeholders for walkthrough. Stakeholders find an issue or something that isn’t quite right now there is real data in the application. And…. rinse and repeat, the process starts over again.

The thing is, creativity is seen as something that stands on its own and is not in the realm of the analytical. This is a societal issue, not just a corporate one. We are more comfortable with the idea that one type of person is good at x while another is good at y. It creates a sense of security for us when every part of product development can be labeled, assigned and allocated in a safe little bite-size piece. That way if anything ever goes wrong, we can point to the piece and fix it just there! NO! Silly nonsense. Process is amazing, I love process and order. But like in nature, order and process must evolve out of necessity. They cannot be overlain like a scaffolding that will solve all of your problems. The problems must themselves be addressed and then the process will follow. At the end of the day, the dissection of the development process makes the work a lot less engaging and a lot less fun. Ironically, by trying to eliminate ambiguity and surprise, we have introduced complexity and redundancy.