Repository navigation
Support JS/TS for config files? #1089
Description
Affected Packages
I assume config package only?
Problem
We wanted to try to load Changeset config using JS/TS to have more flexibility for the configuration flags.
For example, we would like to make the snapshot version template more flexible (for example, to include PR numbers in the version in some cases, and use commit id for others).
Activity
Andarist commentedon Feb 12, 2023
Any strong opinions about this one @emmatown @elliot-nelson ? Overall I'm not a fan of having too many ways to configure tools but it's just so simpler to configure some things dynamically with JS (like the mentioned snapshot version template). Changesets don't really need a serializable config - we won't be parallelizing the work anyhow so JS should be fine here. WDYT?
elliot-nelson commentedon Feb 12, 2023
@Andarist No strong ones! If you own CLI tooling you're part of an ecosystem, and since your
eslintandjestandwebpackandprettier(etc. etc.) all offer Json/JS options, falling in line makes sense to me.I think the danger of jumping to JavaScript config is that once your users can script solutions to problems in your config file, it can hide features that really should be part of your offering, but all of your users are scripting around it instead.
As an example -- one use case in OP is "I want to use pull request numbers for snapshot version template". Makes sense to script this, probably, because the name of
process.env.PULL_REQUEST_NUMBERvaries whether the CI/CD script runs on GitHub Actions or Azure DevOps or Circle CI or Jenkins.But, another use case given in OP is "I want to use one template in some cases, and another in other cases". This might be a missing feature -- maybe it's really common to want to generate one format locally, and another in some cases, and another in other cases.
A way to handle that might be that you support multiple named choices for snapshot generation -- and the call from your pipeline might look like:
(In general, my bias here is that I don't like logic buried in config files -- if there's a choice being made, I like to see that choice from where I'm calling the tool. But other monorepo maintainers could disagree.)
Anyway, sorry for rambling post, TLDR: 👍 : to JS config files, but also 👍 to watching for use cases that the JSON version can't handle and fixing it by adding features.
emmatown commentedon Feb 12, 2023
I’m quite strongly against having a non-static config file because it prevents tools like the Changeset bot from reading able to read the config.
Having a flag for this option or writing a short script to update the config before running versioning seem fine to me.