mirror of
https://github.com/erlef/setup-beam.git
synced 2026-07-22 22:56:07 +00:00
Paulo F. Oliveira
f6a73a7bf1
* Update some dependencies' versions (also, get rid of husky) * Introduce branch dependency execution We want the most important things to fail first and prevent the other ones from executing e.g. if your dist/ is not updated, there's no point seeing the tests fail * Rid ourselves of bloat * Introduce expectations for upcoming version * Tweak whitespace * Tweak our calls to getVersionFromSpec (increase code consistency) * Remove non-used variable * Start coercing on input, stop sorting/maybe prepending 'v' on input We'll deal with all this in a centralized place to make it easier to reason on the code * Revamp our getVersionFromSpec 1. stop accepting maybePrependWithV0, since this is only used in specialized cases 2. sort versions internally (don't expect it to come sorted) 3. compare rc/strict and .includes in a single go (don't separate these) 4. don't expect already coerced version arrays, coerce them when required (the maybeCoerced version had changed already, which means we're smarter at putting stuff inside the version array) 5. raise an exception if a semver-invalid version is not flagged as strict * Reduce our expectations, but still be appropriate to our mission * Update our tests for our new expectations (start the TDD bit) * Execute npm run build-dist and keep results * Increase inter-job dependency * Don't expect markdownlint to be installed remotely * Revert "Increase inter-job dependency" This reverts commit 500b0fe7e9eec1c4f258b4d16b40719ee1d0a1ad. * Revert "Introduce branch dependency execution" This reverts commit fbe1317a800d7722f4e8b668c073218263d0ab17. * Have all the CI workflows run under the same conditions * Fix as per CI results * Re-establish the possibility to match versions like 22.3.4.2.1.0 We cheat on the semver matching: 1. we keep an ordered list of versions that respect e.g. 22.3.4 2. if we match 22.3.4 when fetching a version, we get the last value from the list of versions that respect it, e.g. 22.3.4.2.1.0 (since this is ordered, it should work as previously expected) This increases code complexity for getVersionFromSpec, but hopefully not by much... We also remove throw-based test cases (non-versions will fail later, with null), and add some tests to prove our need code. * Trim out linting practices But still keep them useful