Repository navigation
@babel/core fails in all current variants #1137
Description
Activity
Thank you for the reminder, I will look into it.
Reacted by Mike McCreadyThere appear to be multiple issues, but for some reason, citgm is testing
v8.0.1, whereas the latest version is https://github.com/babel/babel/tree/v8.0.4.https://www.npmjs.com/package/@babel/core?activeTab=versions shows that the npm registry has
v8.0.1as the latest published.$ npm view @babel/core version 8.0.1
Reacted by liuxingbaoyuI see, Babel only publishes packages that have changed.
Can we have citgm always fetch themainbranch?Yes, that can be done with
"head": truein the lookup config.Reacted by liuxingbaoyuThe root cause of the failure is that browserslist is unhappy with the
caniuse-liteprovided in the repo snapshot of Babelv8.0.1.I think this issue can be addressed in the CIGTM script.
Currently cigtm downloads
https://github.com/babel/babel/archive/v$(npm view @babel/core version).tar.gzAs a repo snapshot, the v8.0.1 contains an outdated yarn.lock, which
browserslistis unhappy with. This is never an issue for our downstream npm consumers since the lockfile will not be published.I recommend we implement the following two changes to the cigtm script:
- Fetch the latest stable release version from github.com
Because Babel only publishes changed packages, there are chances that the latest
@babel/coreversion, with the lockfile in the repo snapshot, does not work with latest Node.js. So we should fetch the latest version from github.com rather than npm registry. For example, the following command should print v8.0.4 as of September 9, 2026:git ls-remote --tags --refs https://github.com/babel/babel.git | awk -F/ '{print $NF}' | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n1
Then we can supply the version to the downloader.
- Set the
BROWSERSLIST_IGNORE_OLD_DATAenvironment variable to1in the github workflow:
Per https://github.com/browserslist/browserslist/blob/f46a5b74e75fec2bda62c6520fc2296bda3c0fe3/node.js#L476, it disables the browserslist check.
As for
head: true, I am afraid of noises from the HEAD, things might break especially during the time when Babel merges quite a few feature PRs before we do a minor release. If we sethead: truechances are that an unreleased@babel/coremight break the citgm. Most of time we will fix any conflict/errors after merging, but I don't feel it necessary to pop up the noise to here.If there anybody planning to make changes to the settings for
@babel/corein citgm following on from the previous issue analysis?The alternative would be to add a temporary full skip entry until a fix is available.
Situation
Running
citgm @babel/corefails all testsmacos/ubuntu/windows
Node.js 22/24/26
Steps to reproduce
Run https://github.com/nodejs/citgm/actions/workflows/test-module.yml
Module to test:
@babel/coreCITGM repository to checkout:
nodejs/citgmCITGM GitHub ref to checkout:
mainResult
See https://github.com/MikeMcC399/citgm/actions/runs/34339097913
citgm/lib/lookup.json
Lines 2 to 8 in 4d3d256
cc: @nicolo-ribaudo @JLHwung @liuxingbaoyu