Configure Explorer to show and distinguish generated/derived/related files

[craxal]

VS Code lets you exclude files and folders from the Explorer with the files.exclude setting. This is useful for hiding generated or ignored files while you're working. Sometimes, however, it's useful to see if your workflow is generating the expected files and folders.

I'd like a feature that lets me configure rules for a new setting, perhaps something like files.generated or files.derived. Files and folders that match a rule would appear "faded" or "grayed out" in the Explorer, indicating that they are distinct from the source code. VS Code should also warn me before directly editing a "generated/derived" file, since I should be editing the source file it came from. Another setting could toggle this feature, determining whether generated/derived files are treated the same way excluded files are.

Alternatively, this feature could be tied into the existing files.exclude setting by adding the above-mentioned setting to toggle how excluded files are treated.

[octref]

Curious if you also exclude generated files in .gitignore? We also have feature requests for dimming files matching .gitignore.

[craxal]

Following up. Has there been any discussion on this feature?

[RTSchriner]

@isidorn I see you moved this to backlog. Any updates on this? I came over to VS Code from Atom. I love VS Code but this is a feature I really miss from Atom. Thanks!

[ABNW]

Same here, would really appreciate having the files dimmed in some manner.

[yfernando]

+1

[danielrussellLA]

+1

[craxal]

An example that comes to mind: In C# projects, resource files and XAML files often have auto-generated .cs files associated with them. Visual Studio's Solution Explorer visualizes this relationship by nesting the generated files under their parent source file. I often have closely related files in my TypeScript projects, and I'd love to somehow inform VS Code that my files have this kind of relationship.

[akhil-m]

+1

[dariogriffo]

+1

[rokcarl]

My use case is that I have secrets.env where I store all my secrets. Obviously I don't commit this file, so it's in .gitignore. But because of that, I can't edit this file in VS Code because it doesn't show up at all.

[dmitry1100]

In my case I have Unity project and I develop shaders. Often I need to look for some implementation in standard shaders pack provided with each Unity version. I keep this pack in ignored folder because it is needed only for me but not for other team members and I can't find anything within these files while they are ignored. As a workaround I temporary enable the folder in .gitignore by commenting it. But it is not convenient.

[ronbravo]

One interesting work around I found is that in VsCode's file browser, if you right click and create the file or directory you need (ex: right click -> create file -> .gitignore), it will show up. Not the best solution especially if things are nested but gives a quick and dirty way to do it.

[koliyo]

Same here. Using generated files that I want to see in my VS Code project, but not commit to git repository. Something like files.include or files.generated would be very helpful!

[jpdejavite]

👍

[aesyondu]

I also want this but I don't know how to implement it exactly. Obviously most of the time I don't want search to be polluted with node_modules but sometimes I want to be able to search inside for debugging purposes. Same deal with log files generated by web frameworks.

[fabd]

This is really cumbersome. I routinely alt tab to Sublime Text to open .gitignore'd files. For example I have a local .htaccess file while the public repo has a htaccess_example file.

If that is any help personally I don't care if the files don't show. If I can at least open them with the fuzzy find command palette.

Possible implementation

Alternatively , how about adding a a toggle in the Explorer view (top right, "..." menu), to "show ignored files". When it shows, the command palette would also allow to browse the files.

This solution isn't ideal since the node_modules would also show... then maybe as others suggested I would also add some kind of always_ignore setting for files and folders that will never show, in which case I'd put "node_modules" in there, so when I toggle "show ignored files" I don't see those files, but I would see everything else that .gitignore hides.

[JacksonKearl]

Hello all, I recently took ownership of this ticket and I'm wondering if there is any more work needed here now that files ignored by git are shown greyed out, yet still visible in the explorer and able to be edited.

There are a couple open tickets regarding related functionality:

• Allowing contribution to the explorer title menu, which could be used by extensions like Toggle Excluded Files
• Adding a separate command to quick open files without search.excludes: Simple way to temporarily turn off exclusions for QuickOpen files #15604

If there is more to be done for this ticket please give a concrete example of the missing functionality, otherwise I will close this out.

[craxal]

@JacksonKearl If you look at the title and the original comment, this isn't just about showing or hiding generated/derived files. This is also about indicating files that are related but both still source files that need to be committed, such as .cs code-behind files for .xaml files. Git ignored files doesn't really apply here.

[JacksonKearl]

The API our built in Git extension uses to mark ignored files is available to extensions-at-large to implement their own decorations. This is done via the FileDecorationProvider interface.

The Git extension implements these decorations like so:

vscode/extensions/git/src/decorationProvider.ts

Lines 14 to 85 in d04f317

	class GitIgnoreDecorationProvider implements FileDecorationProvider {
	private static Decoration: FileDecoration = { color: new ThemeColor('gitDecoration.ignoredResourceForeground') };
	readonly onDidChangeFileDecorations: Event<Uri[]>;
	private queue = new Map<string, { repository: Repository; queue: Map<string, PromiseSource<FileDecoration | undefined>>; }>();
	private disposables: Disposable[] = [];
	constructor(private model: Model) {
	this.onDidChangeFileDecorations = fireEvent(anyEvent<any>(
	filterEvent(workspace.onDidSaveTextDocument, e => /\.gitignore$|\.git\/info\/exclude$/.test(e.uri.path)),
	model.onDidOpenRepository,
	model.onDidCloseRepository
	));
	this.disposables.push(window.registerFileDecorationProvider(this));
	}
	async provideFileDecoration(uri: Uri): Promise<FileDecoration | undefined> {
	const repository = this.model.getRepository(uri);
	if (!repository) {
	return;
	}
	let queueItem = this.queue.get(repository.root);
	if (!queueItem) {
	queueItem = { repository, queue: new Map<string, PromiseSource<FileDecoration | undefined>>() };
	this.queue.set(repository.root, queueItem);
	}
	let promiseSource = queueItem.queue.get(uri.fsPath);
	if (!promiseSource) {
	promiseSource = new PromiseSource();
	queueItem!.queue.set(uri.fsPath, promiseSource);
	this.checkIgnoreSoon();
	}
	return await promiseSource.promise;
	}
	@debounce(500)
	private checkIgnoreSoon(): void {
	const queue = new Map(this.queue.entries());
	this.queue.clear();
	for (const [, item] of queue) {
	const paths = [...item.queue.keys()];
	item.repository.checkIgnore(paths).then(ignoreSet => {
	for (const [path, promiseSource] of item.queue.entries()) {
	promiseSource.resolve(ignoreSet.has(path) ? GitIgnoreDecorationProvider.Decoration : undefined);
	}
	}, err => {
	if (err.gitErrorCode !== GitErrorCodes.IsInSubmodule) {
	console.error(err);
	}
	for (const [, promiseSource] of item.queue.entries()) {
	promiseSource.reject(err);
	}
	});
	}
	}
	dispose(): void {
	this.disposables.forEach(d => d.dispose());
	this.queue.clear();
	}
	}

This is a bit more involved than you'd need for the basic cases, but it should provide a good indication of how to implement something like this.

[JacksonKearl]

Closing this issue as extension-candidate due to the availability of the FileDecorationProvider API detailed above.

Feel free to create follow up issues for matters which can not be tackled by an extension.