extension.json: The AL Configuration File Every BC Developer Should Master (But Most Don't)

The configuration file that does the heavy lifting so you don't have to

Yo, I need to tell you about a file that changed how I work.

Most developers I've worked with don't know it exists. But I learned about it on a gig years ago, and it's been quietly saving me hours ever since, even most open-source AL projects I see don't include it.

It just sits there in your .vscode folder. Called extensions.json.

Doesn't sound exciting, right?

But it’s powerful.

It tells VS Code: “Hey, if someone opens this repo, make sure they’ve got the right tools.”

Let me explain.

The File Nobody Talks About

Start a new VS Code project? Easy, Just one command AL: GO! Scaffold an AL project, then boom.. launch.json, check. Maybe settings.json if I’m feeling fancy. But extensions.json? Never even crossed my radar.

For years, I thought I had my setup nailed. Just me, VS Code, the AL Language extension. Waldo CRS, AZ AL, a couple of other helpers I’d install on autopilot. Same ritual every project. My comfort zone.

Then came this US gig. New repo. I clone it, crack it open.

And then.. bam. VS Code throws me a curveball: “Do you want to install the recommended extensions from XXX for this repository?”



I blinked. Recommended by who? Why these? And how did VS Code even know?

That was the moment it hit me: there’s a secret handshake baked into every repo. A file I’d been ignoring all along, Meet extensions.json.

What This File Actually Does (And Why It's Genius)

So what does extensions.json actually do? It’s not just a list, it’s a team agreement. It's saying "Hey, if you're working on THIS project, you should have THESE tools."

When someone new joins your project, they don't have to ask "What extensions do you use?" They just open the workspace, VS Code sees the file ..and boom.. one click installs everything.

But it's more than convenience. It's about shared experience.

When I tell my teammate "Just use the quick fix to declare that variable," I know they can do it. Because we all have the same extensions. We're all working with the same superpowers, like a squad where everyone gets the same gear.

The file in my workspace looks like this:

json
{
    // extensions that make BC development not painful
    "recommendations": [
        "andrzejzwierzchowski.al-code-outline",
        "BartPermentier.al-toolbox",
        "davidfeldhoff.al-codeactions",
        "donjayamanne.githistory",
        "DotJoshJohnson.xml",
        "vjeko.vjeko-al-objid",
        "fluxxusnl.atdd-testscriptor"
        ...
    ]
}

Simple. Powerful. Team enabling.

Why extensions.json Matters More Than You Think

Before this file, here's how it worked:

New developer joins the team. They set up VS Code. Install some extensions. Different ones than you. Maybe they have a formatter, maybe they don't. Maybe their Git visualization is different. Maybe they don't have the AL tools you rely on.

Then you're on a call. "Just use the object designer to find it."

"I don't have that."

"Oh. Um. Well, go to the marketplace and search for..."

15 minutes later, you're back to coding. Maybe.

With extensions.json?

New developer clones the repo. Opens VS Code. Clicks "Install All." 30 seconds later, they have the exact same setup. You can say "use the object designer" and they can actually use it.

It's not revolutionary. It's just smart. But smart things save hours.

The Business Central Extensions That Actually Matter

Okay, so now let me tell you about the extensions in MY extensions.json and why they're there. Not because some article said they're good, but because I personally needed each one.

The Core Stuff (You Need These, Trust Me)

• ms-dynamics-smb.al - This is the AL Language extension. Obviously you have this. If you don't, you're not doing BC development, you're just staring at colored text.
  
  
  
• waldo.crs-al-language-extension - This is Waldo's magic. Automatically renames files when you rename objects. Organizes stuff. Does all the housekeeping you were doing manually like a chump. First time I saw a file rename itself, I felt both amazed and stupid for not having this sooner.
  
  
  
• martonsagi.al-object-designer - If you came from NAV/C/SIDE, you miss the object designer. This brings it back. All your objects in a nice list. Click. Open. Done.
  
  
  
• andrzejzwierzchowski.al-code-outline - Shows all procedures, triggers, variables in a sidebar. My old method was scroll, scroll, scroll. Now? It’s just a list. Click the procedure name. Jump there. Why did I ever scroll? Feels like cheating.
  
  
  

The Ones That Make You Feel Like You're Cheating

• himanshusharma.vscode-al-variable-quickfixes - You use a variable. It's not declared. Red squiggly. Normally you scroll to the top, manually add it. With this? Click the lightbulb. "Declare variable." Done. Right type, right place. Feels illegal.
  
  
  

• davidfeldhoff.al-codeactions - Quick fixes and refactorings. Little suggestions that pop up. "Hey, you could simplify this." Sometimes I listen. Sometimes I don't. But having options is nice.
  
  
  

The Translation Nightmare Solvers

Real talk - I had a project that needed US, Canada, UK, Australia, plus half a dozen European and African languages and translations. These XLIFF files. Manual editing. I wanted to quit.

These three saved me:

• daniel-nt.al-translation-center - Main hub for managing translations. See all your translations in one place.
  
  
  
• daniel-nt.al-translation-snippets - Quick snippets for translation work. Less typing, fewer mistakes.
  
  
  
• rvanbekkum.xliff-sync - Keeps your XLIFF files in sync with your code. You add a caption, it updates the translation files. Automatic. Beautiful.
  
  
  

Together, these turned "I want to cry" into "This is manageable." The project got done. On time. With all three languages. I kept my sanity. Mostly.

The Git Stuff (Because We're Adults With Version Control)

• mhutchie.git-graph - Visual graph of your commits and branches. Before this, I used git log and pretended I understood it. Now I actually understand my git history.
  
  
  
• donjayamanne.githistory - See the history of a file. Who changed it, when, why. Super useful when you find weird code and need to know if it was you or someone else (usually it was me).
  
  
  
• waderyan.gitblame - Shows who last modified each line. Found a bug? See who wrote it. See when. See the commit message. Often the "who" is past-me and the commit message is "fix stuff" which isn't helpful but at least I know.
  
  
  
• srmeyers.git-prefix - Helps keep commit messages consistent. Not exciting. But my project manager can actually read our git history now instead of seeing "wip", "fix", "asdf", "ok this time for real."
  
  
  

The Testing Thing I Avoided Until I Couldn't

• fluxxusnl.atdd-testscriptor - Writing test scenarios. I avoided this for so long. Tests felt like homework. This makes it feel more like writing a story. "Given this setup, when I do this, then this should happen." Still not fun, but way more bearable. Future me thanks past me for writing tests. Sometimes.
  
  
  

The Quality Control Police

stefanmaron.businesscentral-lintercop - This is the stern teacher who catches everything. First time I ran it on my code, I got 73 warnings. SEVENTY-THREE. I was personally offended. How dare this extension judge my code?

I fixed them. All of them. Took a few hours. My code was better. Noticeably better. Cleaner. More consistent. Fewer potential bugs.

Now I can't code without it. It's like having a senior developer reviewing every line, but they never get tired or go on vacation. Sometimes annoying. Always helpful.

The Navigation Tools

• wbrakowski.al-navigator - Jump to definitions, find references, navigate through your code like you actually know where stuff is. Great for when you inherit someone else's project and need to look competent.
  
  
  
• BartPermentier.al-toolbox - Swiss Army knife of AL tools. Does a bunch of random useful things. I forget half of what it can do until I need it, then I remember "oh yeah, AL Toolbox does that."
  
  
  
• nabsolutions.nab-al-tools - More AL utilities. At this point I have multiple tools that do similar things and they all work together somehow. Not gonna question it.
  
  
  
• vjeko.vjeko-al-objid - Helps manage object IDs. In BC development, object IDs matter. This makes them less of a headache.
  
  
  

The API Testing Squad

I do a lot of API integration work. Used to have Postman open in another window, switching back and forth constantly. Now I have three API testing tools IN VS Code and honestly I use all three depending on my mood:

• humao.rest-client - Test APIs with simple HTTP files. Clean, minimal, gets the job done.
  
  
  
• rangav.vscode-thunder-client - Postman-like features but lighter. Nice UI. Sometimes this is what I want.
  
  
  
• tanhakabir.rest-book - Notebook style API testing. Good for documentation. Sometimes this is what I want.
  
  
  

Do I need three? Probably not. Do I have three? Yes. Am I removing any? No.

The TODO Problem I Have

I leave TODO comments everywhere. "TODO: Optimize this", "TODO: Add error handling", "TODO: Why does this even work?"

It's a problem. These two make sure I actually see them:

• Gruntfuggly.todo-tree - Shows all TODOs in a tree view. Can't ignore them when they're in a list staring at you.
  
  
  
• wayou.vscode-todo-highlight - Makes TODOs light up in your code. Bright. Obvious. Annoying. Effective.
  
  
  

I currently have 14 TODOs in my archive project. They're all highlighted. The tree shows them all. I'm still ignoring some. But fewer than before. Progress.

The Visual Stuff That Matters More Than You'd Think

vscode-icons-team.vscode-icons - Pretty icons for files. Sounds superficial. Makes finding files way faster because your brain recognizes icons quicker than reading extensions. That speed adds up over a day.

The Microsoft Essentials

ms-vscode.powershell - I'm on Windows. I write PowerShell scripts. This makes that better. Not glamorous. Necessary.

What Actually Happens When You Use extensions.json

Let me paint you a picture of how this works in real life.

New contractor joins our project. I send them the repo link.

Before extensions.json:

• "Hey, what extensions do I need?"
• "Oh uh, let me make a list..."
• 30 minutes of back-and-forth
• They install most of them
• Miss a few
• Have different versions
• Stuff doesn't work quite the same
• More troubleshooting

After extensions.json:

• They clone the repo
• Open VS Code
• "Do you want to install the recommended extensions for this repository?"
• Click yes
• Make coffee
• Come back
• Everything works
• We start coding

That's the power. Not just the extensions themselves, but the fact that everyone has the SAME extensions. Same tools. Same capabilities. Same experience.

When I say "use the object designer to find that table," everyone knows what I mean. When someone says "just quick-fix that variable," I can do it. No confusion. No "I don't have that extension" moments.

We're all working with the same superpowers.

How To Build Your Own extensions.json

Don't copy mine blindly. These are MY solutions to MY problems. Your problems might be different.

Here's how I'd do it if I started over:

Week 1: The absolute basics

• AL Language (obviously)
• Waldo's CRS Extension
• AL Object Designer
• AZ AL Dev Tools/AL Code Outline
• One Git visualization tool

Work with just those. Find your pain points. Write them down.

Week 2-4: Add solutions to actual problems

• Can't find procedures? Add AL Code Outline
• Variable declarations annoying? Add AL Variable Quick Fixes
• Code looks messy? Add AL Formatter
• Doing translations? Add the translation trio

Every extension should answer a question you're actively asking.

Month 2-3: The quality of life stuff

• Git tools
• API testing tools
• TODO management
• Icon themes

These aren't essential but they make the day better.

The key: Your extensions.json should tell the story of YOUR development journey. Not mine. Not some "top 50 extensions" article. Yours.

Why This Matters for Teams

If you're working solo, you can install whatever you want. Your setup, your rules.

But if you're on a team? If you're ever going to have another person touch this codebase?

Put your recommended extensions in extensions.json.

It's not about forcing your preferences on others. It's about giving them a starting point. A "this is how we work here" guide.

They can ignore it. They can customize it. But at least they know what the team uses.

And when you're pair programming or screen sharing, you're all speaking the same language.

The Real Talk Nobody Tells You

My extensions.json is messy. It has commented-out dreams. It has tools I barely use but can't bring myself to remove.

It's not perfect. It's not optimized. It's not from some carefully researched "best practices" guide.

It's just... mine. Built over months of frustration and discovery. Each extension earned its place by solving a real problem I actually had.

And you know what? It works.

When I work on a project, everything just flows. The tools are there. They work together. I'm not fighting my editor. I'm just coding.

That's what a good extensions.json does. It gets out of your way and lets you work.

My Challenge to You

If you don't have an extensions.json in your workspace, create one. Right now. Add just the extensions you actually use and would recommend to someone joining your project.

Start with 3-5. That's fine. Better than nothing.

If you do have one, when's the last time you looked at it? Are there extensions you installed once and never used? Are there new ones you use daily that aren't listed?

Update it. Make it accurate. Make it useful.

Because someday, someone's going to clone your project. And they're going to see that little notification: "Do you want to install the recommended X extensions for this repository"

Give them the good stuff. Give them the tools that actually help. Give them your hard-won knowledge in an easily installable format.

That's what extensions.json is for.

Real P.S.

The tools are there. The file is simple. The benefits are real.

Stop fighting your editor. Install the extensions. Add them to the JSON. Share them with your team.

Future you will thank present you.

Support for the Community

Found this helpful? Share it with your BC developer community! 🚀

If you've discovered other must-have extensions, have a different setup that works better for your team, or have questions about optimizing your VS Code workspace for Business Central development, drop a comment or reach out! I'll keep this guide updated as new extensions emerge and the BC development landscape evolves.

♻️ Repost to support the Microsoft Dynamics 365 Community and follow Jeffrey Bulanadi for technical insights above and beyond Business Central, AL development, and scalable integration architecture.

Demo Repository

Want to see a working extensions.json in action? Explore the complete setup from this guide:

• .vscode/extensions.json - Full list of recommended extensions
• Source code examples - The AL project referenced throughout
• Workspace settings - Complete VS Code configuration

Check out the BC Extensions Demo Repository on GitHub for copy-paste ready configurations and additional workspace optimization tips!

Helpful References

• VS Code Docs: Workspace Recommended Extensions
• VS Code Docs: Extension Marketplace