vsx: support buildtime 'extensionPack' handling #9425
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vince-fugnitto
added
the
vsx-registry
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
4 times, most recently
from
3820d74
to
c094ab0
Compare
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
2 times, most recently
from
d1e22da
to
e9ff860
Compare
|
Needs to be rebased following #9486. |
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
2 times, most recently
from
621b59a
to
72f0cef
Compare
|
cc @alvsan09 @paul-marechal would you mind reviewing when you get a chance, I appreciate any feedback :) |
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
from
72f0cef
to
8c19823
Compare
alvsan09
approved these changes
Jun 7, 2021
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
3 times, most recently
from
025eede
to
9a33cc2
Compare
|
I'll merge the pull-request a bit later during the week if there are no objections. |
The following commit adds improved support for `extensionPack` plugins defined as builtins. Previously, `extensionPacks` could be referenced as builtins, but they would later be resolved when the application is first started. For large packs (such as vscode builtins) this would result in a long startup time, where extensionPacks would need to be resolved, and then downloaded. The following commit fixes that problem by allowing `extensionPack` to be resolved and fetched at buildtime rather than runtime. In order to implement the improvement, a new dev-package was created (`@theia/ovsx-client`) which includes the common logic for the `cli` and `@theia/vsx-registry` (previously part of the `@theia/vsx-registry`) extension. This logic which interacts with the registry (fetch, search, download, determine compatibility) is now used by the `cli` (buildtime), and `vsx-registry` (runtime). The `@theia/vsx-registry` extension was refactored and cleaned up as a consequence. The idea when resolving builtin extensions is the following: - download extensions like today (master). - determine if any `extensionPack`(s) exist. - fetch individual extension ids. - download latest compatible versions of all individual extension ids. Signed-off-by: vince-fugnitto <vincent.fugnitto@ericsson.com> Co-authored-by: marechal-p <paul.marechal@ericsson.com>
vince-fugnitto
force-pushed
the
vf/ovsx-client
branch
from
9a33cc2
to
9df6be4
Compare
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What it does
Fixes: #9224
The following commit adds improved support for
extensionPackplugins defined as builtins. Previously,extensionPackscould be referenced as builtins, but they would later be resolved when the application is first started. For large packs (such as vscode builtins) this would result in a long startup time, where extensionPacks would need to be resolved, and then downloaded. The following commit fixes that problem by allowingextensionPackto be resolved and fetched at buildtime rather thanruntime.
In order to implement the improvement, a new dev-package was created (
@theia/ovsx-client) which includes the common logic for thecliand@theia/vsx-registry(previously part of the@theia/vsx-registry) extension. This logic which interacts with the registry (fetch, search, download, determine compatibility) is now used by thecli(buildtime), andvsx-registry(runtime). The@theia/vsx-registryextension was refactored and cleaned up as a consequence.The idea when resolving builtin extensions at buildtime is the following:
extensionPack(s) exist.How to test
download-plugins cli:idpresent in the pack the corresponding extension is fetched at its latest compatible version (based on application api level - this can be updated with a flag).vsx-registry:Review checklist
Reminder for reviewers
Signed-off-by: vince-fugnitto vincent.fugnitto@ericsson.com
Co-authored-by: marechal-p paul.marechal@ericsson.com