-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add all vscode built-ins #26
Comments
We removed markdown-language-features for now, because the compatible version was removed from open-vsx. |
I'm working on providing a working replacement for the markdown-language-features extension, and publishing it on open-vsx programmatically. See: eclipse-theia/vscode-builtin-extensions#14 (comment) |
|
#81 is related |
Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Remove @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Remove @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Remove @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Remove @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Went with an older version of ms-vscode.js-debug. The one we used required a slightly newer API than we have and apparently was not fully functional. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
ATM we have one pack, that lists all vscode-builtin extensions. We could create multiple, giving some choice about which ones to install or not. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible, wr to the vscode extensions API that the current app supports. So no update of version needed, and we still get fresh as possible extensions, every build (assuming eventual build-time resolution of pack dependencies). A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Removed @theia/git in favor of the vscode built-in git. This permits using popular extensions such as GitLens. Closes #61 Potentially closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, pass a certain older version. These we need to install the old way, overriding the pack's newer version. e.g.: `markdown-language-features` requires v1.39.2 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, with the version pulled by the pack. These we need to pin to a specific version, that's known to work, using the old way. e.g.: `vscode.git` requires v1.52.1 instead of v1.50.0 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
We now have an extension pack, that lists all vscode-builtin extensions. As a first step, let's aim to have more features than not, and use that pack. For the most part, extensions listed in a pack should be installed, at the latest version that is compatible with the currently used Theia framework version, wr to the vscode extensions API. We need not manually update the version of the built-in extensions, any more. A few of the vscode built-in extensions do not work well, with the version pulled by the pack. These we need to pin to a specific version, that's known to work, using the old way. e.g.: `vscode.git` requires v1.52.1 instead of v1.50.0 Closes #26 Signed-off-by: Marc Dumais <[email protected]>
Adding all built-ins will improve compatibility with vscode extensions that are potentially installed by users. For a list see this package.json.
This was an idea of @marcdumais-work, see comment here.
The text was updated successfully, but these errors were encountered: