Scope-specific build providers

[Gawdl3y]

Proposition

There should be the ability for packages to specify scope-specific build providers, that are automatically checked for eligibility based on the current file that is open. The automatic check would just test to see if the active tab has the scope (example: .source.xml). When the user focuses on a different tab, the scope targets are refreshed for the new active file.

Alternatively, instead of scopes, file extensions could be used. They would be extension-specific providers, I suppose. Regardless, I'll refer to these as "scoped providers".

Details

• isEligible() should probably not be a method on scoped providers.
• Perhaps the scoped provider objects should not be destroyed and re-constructed upon target refresh, but instead reused?
  • If the objects are reused, the current file name/extension and cwd should be given as arguments to settings() rather than the constructor.
  • If the objects are re-constructed, they should be given as arguments to the constructor just like cwd is currently.
• Scoped build providers should be refreshed separately from the current regular build providers.
  • build:refresh-targets should refresh the scoped providers in addition to the regular ones.
  • The refresh event emitted from regular providers should not refresh the scoped providers, just the regular ones.
  • The refresh event emitted from scoped providers should refresh just the scoped ones.
  • Another emittable event, refresh-all, should refresh all providers (maybe not necessary).
  • Perhaps if the objects are reused, only the emitting scoped provider should be refreshed (unless refresh-all)?
• The scopes/extensions (whichever) should be specified either as just a single string, or an array of strings returned from a scopes()/extensions() method on the scoped provider.
• consumeBuilder would be updated to also accept an object of this structure:

{
    "normal": [SomeProviderClass, SomeOtherProviderClass],
    "scoped": [SomeScopedProviderClass]
}

Reasoning

This would allow providers to only provide build targets relevant to the currently-opened file if they're only applicable to certain file types/scopes, rather than providing a persistent target config that may not work at all on most files. The refreshing of scoped providers should be made as efficient as possible, since they'll get refreshed much more often.

If one were to replicate this functionality in a current build provider, it'd have to refresh all of the providers every time the user switches tabs, which is certainly not ideal from a performance standpoint. If multiple packages desire this behaviour, several refreshes could be triggered at once. Furthermore, it'd simply be a lot nicer to develop with this functionality built-in to the build package.

[Gawdl3y]

Updating consumeBuilder to take an object would actually be unnecessary; just an array of all builders would do. We could check to see if one is a scoped provider simply by checking for the existence of the scopes()/extensions() method.

[Gawdl3y]

As an example, I'd like to add assembly/disassembly support to my build-papyrus package. Assembly would only work on .source.papyrus/.psc files, and disassembly would only work on .source.compiled-papyrus/.pex files.

[noseglid]

I am sorry for taking ages to reply to this.

This is an interesting idea. I haven't thought too much about how to solve this, but would it be possible to simple include a scope key in build objects and those targets would only be available when a file with that scope (e.g. .source.papyrus) is open.

In your assembly/disassembly example it could look something like this:

{
  "cmd": "papyrus-disassemble",
  "args": [ "{FILE_ACTIVE}" ],
  "scope": ".source.papyrus"
}

[noseglid]

@Gawdl3y would that solve your use-case?