-
Notifications
You must be signed in to change notification settings - Fork 395
Download compatibility profiles lazily from a remote feed rather than shipping them #1148
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
Comments
A lot worse than "double its size," at least in some cases. In my installation as part of |
Doubles the size of the compressed artefact. When installed, it's considerably larger |
Can we not shell this out as a separate module that requires PSScriptAnalzyer for just the compatibility profiles? |
JFYI, folks, we are having a problem with these files in intellij-powershell, and for now I'm going to just delete them from PSScriptAnalyzer bundled into our distribution. Everything else seems to work fine, and I am very hesitant to increase the unpacked plugin size tenfold in a new update :( Some kind of on-demand downloading or consuming the compatibility rules in the packed form would be very nice. I am ready to work/collaborate on this if you have an acceptable solution in mind. Or help on brainstorming if necessary. |
Currently compatibility profiles for the UseCompatibleTypes and UseCompatibleCommands rules ship with PSSA and effectively double its size.
This represents large overhead for users who don't use these rules or who don't want all the profiles we ship by default.
Ideally the rules should have a way of identifying filesystem and remote assets, and when rules are run, download/install any remote assets not already on the machine. This will also require cataloguing remote assets in a systematic and dependable way.
Proposed implementation
One solution is to have rules as NuGet assets (taking care of both hosting and caching), and specifying profiles as URIs, so that
file://
andhttps://
(for example) profiles can be easily distinguished.This may create an unnecessary dependency on NuGet however.
Whatever the implementation it will need to:
The text was updated successfully, but these errors were encountered: