Azure / Azure/bicep

Support for local file registries

Open
#19,883 8 comments 0 reactions 1 assignee Claimed by @shenglol View on GitHub
discussion enhancement
Dominant language
Bicep
Stars
3.6k
Forks
830
Avg merge
1d 2h
Merged PRs (30d)
79

Description

**Is your feature request related to a problem? Please describe.**

BICEP's primary mechanism for sharing modules between different deployment templates is via module registries. These work well when the modules need to be shared across repositories and versioning is critical; however, the concept doesn't map well onto smaller monorepos where the feature team and the platform team are the same. In these contexts, a registry inhibits the velocity of making the kind of e2e changes that a monorepo aims to enable.

In absence of some sort of module sharing capability, importing bicep modules can become brittle because the imported module must be referenced relative to the current module. This can lead to some really gnarly imports statements like:

`import * as default from '../../shared/module/root/dir/mymodule.bicep'`

Hope you don't have any plans to change the location of that module anytime soon. In my particular case, internal deployment orchestration tooling can make referencing shared modules across different deployments challenging.

**Describe the solution you'd like**

Just recently @SimonWahlin closed #19452 which adds the ability to explicitly mock a registry module with a local file. Before arriving at the solution for this `moduleAliasesMock` concept, the discussion around this pull request brought up the topic of local module registries, something akin to:

_bicepconfig.json_

```json
{
"moduleAliases": {
"local": {
"SharedModuleRoot": {
"mapToFilePath": "../../shared/module/root"
}
}
}
}
```

and the above import statement would be something like:

```bicep
import * as default from 'local/SharedModuleRoot:dir/mymodule'
```

* I imagine tags would not be supported. Pinning to a git commit sha id could be cool, but certainly out of scope for an initial implementation.
* I think I'd prefer `fs` over `local` for the module alias property identifier, but that's splitting hairs.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.