-
Notifications
You must be signed in to change notification settings - Fork 206
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
Specifying version of mixin in porter.yaml #3136
Comments
Hey!
As discussed this would be a schema change. We will have to add a function that checks what mixins are installed and if the version we want is installed. We currently have this function which we may be able to dive into and extend |
Can we close this issue now? I know there was talk of maybe having it auto download the right version, or maybe having many installed at the same time and selected the right one? |
@kurtschenk @dgannon991 implemented syntax implemented for specifying that a specific version of a mixin have to be installed when building the bundle. The version of the bundle can be specified using the following syntax: mixins:
[email protected]:
clientVersion: 1.1.0 The correct version of the mixin have to be installed manually, but if you don't have the correct version installed, linting will fail. Do you believe it solves you request? |
Assuming this was solved in #3215. If this is not the case please create a new issue |
Is your feature request related to a problem? Please describe.
Porter has mixins which are similar to plugins or packages that are listed in the porter.yaml file. However, the specific version of the mixin to install can only be provided in the Porter command. As a developer who has experience working with npm, NuGet modules, I find this limitation to be problematic.
Describe the solution you'd like
It would be more efficient to track mixin versions in the yaml file, as it is done in files like package.json and csproj, especially when it comes to debugging and dealing with broken CI. When it is in the porter.yaml, you can be sure the right version of the mixin matches what you have tested: the package behaves the same all through the development and deployment lifecycle.
Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: