Ошибки и ограничения исходного подхода
- Метод свёртки с умножением на 100: исходная функция фактически вычисляет
$$value=(((0\times 100+a_1)\times 100+a_2)\times 100+a_3)\dots$$ Поэтому для версий $a$ и $b$ сравнивается не покомпонентно, а их «числовая упаковка». Это даёт неправильные результаты:
- длина версий важна: $"1"\mapsto 1$, а $"1.0"\mapsto 1\times 100+0=100$ — разные значения, тогда как версии должны считаться равными;
- ограничение на размер компонента: схема работает корректно только если все компоненты < 100; большие компоненты или произвольное число компонентов ломают упорядочение;
- потеря информации о «пре-релизах» и метаданных (семантические версии: `1.0.0-alpha`, `+build`) — не поддерживаются;
- некорректная обработка нечисловых сегментов (пустые, буквенные) и ведущих нулей.
Корректная реализация (покомпонентное числовое сравнение)
- Идея: разбить строки по точке, привести каждую часть к Integer (проверить), при сравнении пройтись по максимуму длин, отсутствующие части считать нулём. Это даёт ожидаемое лексикографическое (по числам) упорядочение.
Пример тестируемой реализации:
function cmp(a, b) {
if (a === b) return 0;
const toNums = s => String(s).split('.').map(x => {
if (x === '') return 0; // поддержка "1." или ".1"
if (!/^\d+$/.test(x)) throw new TypeError('Некорректный числовой сегмент: ' + x);
// Number безопасен для целых, но используем parseInt для ясности
return parseInt(x, 10);
});
const A = toNums(a);
const B = toNums(b);
const len = Math.max(A.length, B.length);
for (let i = 0; i < len; i++) {
const ai = i < A.length ? A[i] : 0;
const bi = i < B.length ? B[i] : 0;
if (ai !== bi) return ai < bi ? -1 : 1;
}
return 0;
}
Пояснения к реализации:
- Отдельно проверяем, что сегмент состоит только из цифр; при обнаружении некорректного сегмента выбрасываем ошибку (чтобы не молчаливо приводить к NaN).
- Отсутствующие сегменты интерпретируются как $0$ (т.е. $1=1.0=\mathrm{1.0.0}$).
- Вернём $-1,0,1$ для упрощённого использования в sort и проч.
Ограничения этой реализации
- Не реализует семантическую версификацию (pre-release идентификаторы, build-метаданные). В семвере, например, `1.0.0-alpha` < `1.0.0`, и префиксы сравниваются по специальным правилам. Для полного соответствия семантической версии используйте библиотеку semver (npm-пакет `semver`) или реализуйте полный парсер/компаратор по спецификации.
- Не поддерживаются буквенные/миксовые сегменты (намеренно — либо бросаем ошибку, либо нужно расширить логику).
Набор тестов (можно запускать в Node.js или браузере):
const tests = [
// равные
['1', '1.0', 0],
['1.0.0', '1', 0],
['01.002', '1.2', 0], // ведущие нули
// разные
['1.2.3', '1.2.4', -1],
['1.2.10', '1.2.2', 1],
['1.0', '1.0.0.0.1', -1], // более длинная с ненулевым хвостом
['1.0.100', '1.0.2', 1], // большие компоненты
['0.9', '1', -1],
// крайние случаи
['1.', '1.0', 0], // пустой сегмент трактуется как 0
];
for (const [a, b, expected] of tests) {
const got = cmp(a, b);
console.assert(
Math.sign(got) === Math.sign(expected),
`FAIL: cmp("${a}","${b}") => ${got}, expected ${expected}`
);
}
console.log('Tests finished');
Тесты дополнительно нужно расширить на:
- некорректные входы: `["1.a","1.0"]` — ожидать TypeError;
- очень длинные версии и большие числа (проверить, что parseInt справляется);
- проверку стабильности сортировки на массиве строк.
Рекомендация
- Если нужна совместимость с семантической версией (pre-release, build, сравнения по правилам semver) — используйте npm-пакет `semver` или реализуйте парсер по спецификации. Для простых числовых «дот»-версий предложенный покомпонентный подход корректен и предсказуем.