Powershell: NPM'ish package.json for 'Polynumerous' Deployment Types

[doesitscript]

I'm providing a bit of background to better express a possible need... Self-maintainability is complex, often difficult to explain, and requires knowledge of scattered community projects. Currently PSdepends addresses some of the need to handle some project requirements, however I think what is happening is that we are missing a standard of build a project from source project, gather requirements, create an inventory of these requirements (e.g. Ruby.lock). A project should make it clear what method it runs tests at the developers desktop, but also what task is used to promote the build through the pipeline, as well provide a way to define development environment dependencies.

The need for encouraging a standard or scaffolding seems impending at the point that we have Plaster now. An organization can now distribute templates such as a PS Module template, a DSC Module, or an Arm Template PS project and couple with them tasks that perform common operations such as installing the module or deploying tests to target nodes. Currently these tasks are being handled either as inline-code in VSCode's tasks.json or in scripts themselves but referenced within VSCode.

With this functionality scattered and not standardized, delivery pipelines are like the wild west possibly slowing down community adoption and making it difficult to manage these pipelines in automated fashions.

As a point of reference, NPM's & package.json's capabilities is what is missing in the PowerShell world even though we often deal with very complex projects. If this capability was available in a more standard format, we could build entire pipelines from project inception (aka project generators such as the VSTS/Azure generator located here: https://github.com/DarqueWarrior/generator-team)

Thank you for this great product that has made it possible to consider these ideas.

[michaeltlombardi]

Strongly suggest that, instead of rebuilding from scratch, we consider adopting/boosting PSDepend and @RamblingCookieMonster's work on it.

If there's something missing from the implementation of managing dependencies in PowerShell there, suggest we improve on it.

[michaeltlombardi]

On a related note, there's been talk in the community of packaging up tasks and shipping those around, and that functionality maybe finding a home in Psake. I think @gaelcolas may have done some work in this area and others (@cdhunt, @devblackops?) are maintaining tasks for their orgs in similar fashion?

[RamblingCookieMonster]

Focusing just on the dependency management, a few thoughts:

• IMHO this should not be part of PowerShell; even if the PowerShell team took this on, IMHO it should be a separate project, ideally a PowerShell module
• IMHO it should allow multiple and extensible dependency types - given that PowerShell is often used as a glue language, supporting dependencies for the different systems and languages commonly glued together would be helpful
• IMHO it should be written by folks who know what they are doing, both from a development perspective and a use/requirements/operations perspective (I don't meet the former, and only have a bit of the latter). PSDepend was written to do a few things I thought would be helpful, with awesome contributions along the way - that said, the code/design has never been refactored, is messy as hell, and will need serious work for core/xplat support
• Edit: It should support PowerShell Core and xplat, with allowances for OS specific dependency types
• More (e.g. min or max version support). These are just initial thoughts given that PSDepend came up...

So!

I'd be happy if folks contributed to PSDepend, but perhaps even more happy if the PowerShell team, or other more knowledgeable folks crafted a dependency management module from the ground up, even if they borrow ideas

Cheers!

[doesitscript]

One really good thing about PSDepend is its extensibility. Agreed with the building of a separate module, even PSDeploy or its design concepts could be used within that module to handle staging files in correct locations for further work, e.g. tags could be used tie into the task concept.

...it should allow multiple and extensible dependency types - given that PowerShell is often used as a glue language.

Going into the linux world and with docker coming down the pipeline, we need to be able to juggle more skills than before. These tasks are common, but are being addressed by custom scripts in each project.

...it should be written by folks who know what they are doing...

@RamblingCookieMonster Your modules are great and they work well, thank you.

PS projects seem to lean towards building other products, essentially PS projects would benefit from a build system or language. However without some sort of contribution or blessing from Microsoft, community work would be harder to integrate with other existing tools such as vscode.

[michaeltlombardi]

CC @Jaykul for his polynumerous opinions. ;)

[michaeltlombardi]

I'd, personally, rather see work on a major revision of PSDepend than a separate project. There's stuff to refactor and improve (isn't there always?), but the DSL has come along nicely and it's got community backing and recognition.

[devblackops]

Going back to shared tasks via psake, there were discussions at last year's PowerShell Summit about the desire for psake to support shared task modules (apart from how you can just bundle up your task code in module functions and have thin psake tasks call them). As far as I know, there has been no movement on that.