Open barneycarroll opened 2 years ago
Even more alarmingly, I could not find an easy way to find the correct tests with the documented approach. We essentially end up in a situation where there all of a sudden appear false negatives based on our instructions, which implies that someone needs to be alert enough to roll back the local changes advertised as canonical.
As a short-term fix, we could instruct users to just add a postinstall
step that simply copies the right binary into node_modules
.
Just ran into this. Here's my package.json postinstall script solution:
"scripts": {
"postinstall": "ln -sf ../ospec/bin/ospec node_modules/.bin/ospec"
},
Following on from the discussion starting here in the chat.
Mithril's internal ospec is deprecated and
console.warn
s to this effect on execution, recommending the canonical npm install ofospec
. However, installing this as directed doesn't override Mithril's binary path binding for its internal ospec. From my tests, whichever is installed first, installing bothmithril
&ospec
always results in the Mithril's ospec binding taking precedence; @orbitbot says he is able to get ospec to take precedence based on installation sequence, but I couldn't replicate.The issue of conflicting binary path registrations in npm package dependencies has been raised at least a couple of times (npm#7130 & npm#9040) but the trail has run cold seemingly without resolution.
I've raised a discussion on the npm Github org feedback site – but maybe I ought to revive one of the issues above or file a new one?
In the meantime we might be able to advise a hack to account for the current deprecation warning's failure. 🤔