Fix #6647

[busykai]

Make sure the preference order is the right one. This could partial fix if @dangoor would want to change the adding to scope as per order of call (as opposed to order of resolving promises which is how it is done now).

[RaymondLim]

I tested with your changes and it seems to fix all the scenarios in #6647.

[dangoor]

@busykai Your solution to the problem seems correct. I hadn't made the connection that the session MemoryStorage-based Scope would be added first.

The one concern I have is the possibility that your extension could try to set a pref before the session scope has been added. Does that seem like a possibility?

That kind of problem in your extension would not be something that we'd need to address in sprint 36, I think, but it's good to consider if we need to address it in 37. Maybe we add an event for when the preference manager is completely configured. Thinking about it, that would only be a couple more lines on top of this fix, if it seemed necessary.

What do you think?

[busykai]

@dangoor I do not think it's likely. However, I do agree, that it's not guaranteed by how code is organized, but by the amount of IO between the two events (all the languages are loaded + all the extensions from default and dev). And it's not nice.

I think it could be done through an additional event as you describe or it could also be done as part of the init process (in document ready).

Currently init is done as sequence of LanguageManager => ExtensionsManager => ProjectManager => app ready, it could be easily done as (PreferencesManager and LanguageManager) => ExtensionsManager => ProjectManager => app ready if PreferencesManager exposed a promise (in a similar way LanguageManager does it). That would guarantee that it will be initialized by the time extensions are loaded.

Aside from that, I was thinking organizing a queue in PreferencesSystem so that scopes would be loaded in call order and as their storage is loaded, but it does seem too invasive and there will not be too many "system" scopes to chain them "manually" as this PR does. Those extensions who install their scopes should take care of their proper loading and handling themselves.

[dangoor]

@busykai Making sure that the base scopes exist before initializing extensions seems like a good idea.

Another way to approach this would be to have some kind of general name for the path-based scopes so that the session scope can explicitly add itself before the path-based scopes. If we did that, there may not be a need for a full queue for scopes.

I'll go ahead and merge this branch into release and master.