score-spec / score-spec/spec

[FEATURE] Custom placeholder patterns in files

Open
#108 12 comments 0 reactions 1 assignee View on GitHub

@Abhishek9639 is already working on this.

Since Apr 14, 2026.

new feature/idea
Dominant language
Makefile
Stars
8.1k
Forks
2.1k
PR merge metrics
No merged PRs in 30d

Description

Detailed description

When using the files feature in Score, it is often useful to embed placeholders. Unfortunately, the placeholder syntax in Score ${...} is very commonly used and so can result in ambiguities.

It is possible to escape all of the other non-score placeholders, but this results in potentially major changes to a config file just to adopt score. A better approach would be to be able to define a custom pattern for a placeholder in a file - for example %{...} that could leave the existing file intact except for actual score placeholders.

Examples for config files that use ${...} as a variable expansion pattern:

Context

Adopting score should not require major changes to existing configuration - for example escaping existing variable expansions. This could for example mean that the configuration file does not work with existing local tooling.

This only makes sense for files rather than variables - as variables are only in the score of the score file anyway.

NOTE Score already supports noExpand on the files object to avoid processing placeholders.

Possible implementation

There are a number of approaches that could be taken.

  1. Allow changing of the leading $ with another character. E.g % for %{...} style placeholders.
  2. Supply start and end placeholders entirely. E.g. << and >> for <<...>> style placeholders.

1 is simpler but 2 is more flexible as there could be unforseen situations where { is an integral part of the configuration language and a non overlapping prefix cannot be ruled out.

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.