Don't show extension recommendations for common .env file extensions

[digitarald]

Steps to Reproduce: Open a .env.local, .env.production, .env.example, or .env.development file.

Actual: Keeps prompting for each new .env file extension. Search results are not useful.

Extension search for a production file:

Expected: Just edit the file plainly. It doesn't need much to write env files.

cc @sandy081 @isidorn

[isidorn]

@digitarald good catch.

Create test.production and open it in VS Code. You will get the same prompt.
Create test.isidor -> you will not get the prompt.
So it seems like VS Code will offer recommendations for some file extensions for which it does not have an extension installed but not for all extensions.
@sandy081 is there a hard coded list of extensions for this? How does this work? Should we just remove .production from this list?

[digitarald]

Looks like the recommendation is only shown when the ext: search finds extension for that type:

vscode/src/vs/workbench/contrib/extensions/browser/fileBasedRecommendations.ts

Lines 318 to 322 in edbf56a

	const text = `ext:${fileExtension}`;
	const pager = await this.extensionsWorkbenchService.queryGallery({ text, pageSize: 100 }, CancellationToken.None);
	if (pager.firstPage.length === 0) {
	return;
	}

[digitarald]

A Marketplace search bug adds to the confusion: ext:production shows the colonize extension because production is in its tags; which doesn't seem a useful field to match ext: against.

[sandy081]

It's not an hardcoded list. We check if there are extensions supporting such a file extension and prompt users to install if one of them is not installed as shown by @digitarald.

[isidorn]

Ok, thanks for clarifying.
So the root cause is that searching for ext:production gives too many results. Is this syntax supposed to only give extension which support the given file extension? How do we detect if an extension supports a file extension, how do we mark it - with a tag?

fyi @mayankmaheshwari18

[sandy081]

It is not giving too many results, instead it is giving correct results. In fact ext:production is VS Code syntax and we internally convert this into following tags filters: __ext_production, __ext_.production, production - Query for all extensions with above tags.

vsce generates these tags by looking at the language contributions in extension package.json file.

[digitarald]

@sandy081 could you explain "instead it is giving correct results". It seems in the examples above that resolving tags for file extension searches yields many false positives. Could this maybe have worked better when the marketplace had less extensions?

In the past we have seen that a shorter list of more curated results helped users. Maybe we could run an experiment if the fuzzier/broader search yields more installs than a shorter/more-accurate search.

[sandy081]

could you explain "instead it is giving correct results". It seems in the examples above that resolving tags for file extension searches yields many false positives. Could this maybe have worked better when the marketplace had less extensions?

Sure. As I mentioned in my previous comment, ext:production is converted this following tags filters: __ext_production, __ext_.production, production. MP is returning all extensions that contain atleast one of these tags. It seems some of the extensions are having the production tag and it is ambiguous that if this tag is for a language or not.

[digitarald]

The same tag problem applies to .development, .example, .local, etc as well. I opened a separate issue on that nevertheless: #140050

The original issue was about the limited benefit that .env files get from the available extensions and that prompting is too intrusive. This is somewhat validated by the low install numbers for those extensions and the low engagement with the prompt. I understand that we don't have an existing ignore list for extensions that could be utilized to exclude extensions from being prompted for.

What do others think about special-casing .env extensions?

[isidorn]

I would not like if we introduced a special case for .env extensions -> that sounds like a hack.
Instead I would prefer if we improve our heuristic when we show the extension recommendation toast. I am not sure how.
@sandy081 can we look at the contributes.language field in the package.json? Or we do not have this info at this moment?

@digitarald are there other file extensions where the toast is showing up and it should not?

[sandy081]

@sandy081 can we look at the contributes.language field in the package.json? Or we do not have this info at this moment?

I do not think this will help. The root problem here is to come up with proper non generic tags to search in MP.

[digitarald]

@isidorn the top file extensions by cancelation count: development, example, production, local, config, env, pdf, plist, dev, out, pbxproj, bak, test, snap, tpl, sample, dat, template, tf, pub, key.

I'd argue that most (with exceptions, like pbxproj) are rather generic. I haven't tried searching for them, but will give it a shot to test the query discussions from #140050.

[isidorn]

Ok, then a hack alternative would be to just take this list of top file extensions by cancelation count from @digitarald and have them in our code as a filter list for which we do not show recommendations....

I am open to suggestions...

[miguelsolorio]

👀 Related thread from Reddit

[isidorn]

I am glad we are bringing comedy gold.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!