@jrieken good catch. I found more though:

• vs/platform/actions/common/resourceContextKey => vs/editor/common/services/modeService
• vs/platform/extensionManagement/test/common/extensionEnablementService.test => vs/workbench/services/storage/common/storageService
• vs/editor/contrib/indentation/common/indentation.ts => vs/workbench/services/quickopen/common/quickOpenService
• vs/editor/contrib/suggest/electron-browser/snippetCompletion.ts => vs/workbench/services/quickopen/common/quickOpenService

Maybe we could enrich the layeringRule to more rules:

• base: []
• platform: [base]
• editor: [platform, base]
• workbench: [platform, base, editor]

• vs/editor/contrib/suggest/electron-browser/snippetCompletion.ts => vs/workbench/services/quickopen/common/quickOpenService

I think that shows a nice problem with our layering. We somehow don't only separate between target runtimes (JS, browser, electron-main,browser) but also between platform, editor, workbench, base. This is like a 2-dimensional layering and I wonder if that makes things artificially complicated.

In the sample above I wanna contain all suggest-related features in one folder. That makes it easy to find/navigate/understand. Also I have structured it along the runtimes (common/browser/electron) but it conflicts with the goal of also structuring along workbench-editor et al. Somehow conflicting goals and abstraction for little gain. I wonder if we can give/reduce the 2 layer in some way

I think what we used to do in that case is to put the editor contribution into the vs/workbench/parts folder because it can only work if the workbench is there. But yeah, that moves it away from snippets in general.

To express the same intent I have put it into the electron-browser folder. The workbench is the only thing that runs from there.

I am not sure what is the good solution for tests here. For eg extensionEnablementService has a dependency on storageService where both interfaces are in platform. But implementation of storageService lies in workbench.

Either,

• Exclude this for tests because they need to instantiate the implementations themselves.
• Create a mock of such services in tests. This would be tedious. Tests will be more reliable if using real implementations
• Make sure definitions and implementations remain in the same layer. I think StorageService implementation can be moved as all its dependencies are in platform.

In this case, I would go for last option. But in general I would allow tests to instantiate the implementations.

src/vs/editor/contrib/indentation/common/indentation.ts layer break introduced by @isidorn in f01ee98

@joaomoreno and @bpasero: product.ts and package.ts layering issues. Requires nodejs and respective json files.

@jrieken Fixed those.

Moved storage service to package layer.

@jrieken All issues reported here are fixed. You can close this.