Disable extension in folders where manifest.json is found for bedrock edition

[tryashtar]

Just opening a bedrock mcfunction file gives a bunch of errors

[Kesuaheli]

Yeah, because it's only made for Java Edition data packs. Most of the commands in Bedrock Edition behaviour packs have a completely different syntax.

As far as I know, it is not planned at all to support Bedrock behaviour packs. It's not even thought about to be planned in the future.

Microsoft themselves have recommended these two extensions for VSCode when making Bedrock Add-Ons:

• "Bedrock Definitions" by destru7i0n
• "Blockception's Minecraft Bedrock Development" by Blockception Ltd

But these two, however, collide with Java Edition data packs and give you a bunch of errors because they aren't made for Java Edition.*
If you are developing both Java Edition data packs and Bedrock Edition behaviour packs, you have to disable the other extension(s) in VSCode while not using it. If you navigate to your extensions tab and select the extension you want to disable, there's an option for uninstalling the extension entirely, an option for disabling globally and for disabling for this workspace.

*I do, too, use all three of these extensions. I found that the Bedrock ones give you errors not only in Java Edition data packs but in every other JSON file because it thinks you're trying to define something for a Bedrock Add-Ons.
I therefore have to recommend that you disable the Bedrock ones globally and only enable them when developing Bedrock Add-Ons.

[tryashtar]

I know, I made an issue there too :) Blockception/VSCode-Bedrock-Development-Extension#564

[Kesuaheli]

Oh, so this issue addresses the fact that it should recognise Bedrock behaviour pack .mcfunction and not be enabled for these files?

[tryashtar]

Yeah, it would be very cool if this extension checked for pack.mcmeta and that one looked for manifest.json

[misode]

Would it not be possible to disable the extension in your workspace whenever you're working with Bedrock functions? Explicitly requiring a pack.mcmeta seems like a downgrade, because I would still want lone mcfunction files to receive language support. Maybe we could check for a manifest.json file and disable the language features yourselves?

[Kesuaheli]

I would still want lone mcfunction files to receive language support.

I fully agree with that. Otherwise it would be a pretty big downgrade.
I too thought about checking if this file is inside a bedrock environment. Thats what I meant by "it should recognise Bedrock behaviour packs". I think checking for the manifest.json on the same level as the functions/ folder would be the best approach.

A super solution whould be to check if the lines, that causes the errors, are valid with bedrock syntax. And then automatically disable highlighting. I know its a whole nother level. At this point Spyglass can almost think about supporting Bedrock Add-Ons.

[tryashtar]

That's fair, I'd want lonely function files to work too, although without a pack file it's impossible to know not only which edition it's for, but which version, so that might be annoying

[MulverineX]

In IMP Doc v2 (or whatever it ends up being called) we could have a header comment that explicitly declares the function's game version. @vdvman1 @RitikShah

Default behavior here shouldn't change at all though unless its a workspace with a bedrock manifest.json. Maybe also have an editor command (ctrl+shift+p) to disable the extension within the current file.

Also, we're not ruling out Bedrock support in this extension, its just not something we're going to be spending time on for a while.

[misode]

Moved this to the backlog because this is less urgent now. You can manually specify this folder in env.exclude