We have a huge JavaScript application at work. The codebase is an Ember app with a ton of engines and in-repo addons. Tens of thousands of files and as many tests. I initially tried including a single .jsconfig file at the root of the project, but vscode would bog down with any attempt at “Go to definition” and intellisense for imports never worked even after excluding node_modules and all of the build output directories.

The solution I ultimately landed on was to include a separate .jsconfig file for each of the subdirectories that comprised a logical unit. Every addon or engine had its own .jsconfig without any config at the root of the project. For projects based on other frameworks (Vue, React, etc), the directory structure would be different, but the basic concept would be the same. To allow each subdirectory to resolve files from the root, I added a baseUrl config which pointed to the root. So I ended up with the config files structured something like this:


The key to getting this to resolve files for intellisense features was adding the baseUrl configuration. The baseUrl should point to the location where absolute paths should be resolved from. In many projects, this would be a src directory, but Ember doesn’t follow that particular convention at the moment so if your project has a src directory where absolute paths are resolved from you’ll need to adjust the baseUrl config accordingly. Anyway, given the structure above, my baseUrl looks like the following:

// for the app directory
baseUrl: '../'

// for the engine and addon directories
baseUrl: '../../'

Of course, this would be tedious for many subdirectories, so I created a simple script to auto-generate the config files with the correct baseUrl and path mappings. I spent quite some time researching how to set this up for a such a large codebase but didn’t find much help. So, if anyone is looking for a solution to this problem, this seems to work pretty well. It would be ideal to have a centralized configuration file at the root of the project, but for now this is the best approach I’ve found.

The performance increase for intellisense and go to definition after implementing this was pretty remarkable and I could forsee it scaling to a much larger codebase.