https://pantsbuild.org/ logo
Join Slack
Powered by
Happy Friday! Which shall henceforth be known as G...
# development
h
Happy Friday! Which shall henceforth be known as Get() Deprecation Day! https://github.com/pantsbuild/pants/pull/22709
🔥 1
w
I made a comment, can be discussed here if needed re: the removal note. Seems quick
Would break plugins (I think?)
h
Why would this break plugins?
Unless you sent warnings to error
Which you choose on purpose
w
As in, removing 
Get
in 2.31, aka, next release
Just checked, our deprecation policy (https://www.pantsbuild.org/stable/docs/releases/deprecation-policy) is 1 minor, so 🤷
h
Yeah, and that’s for end user features. We have always emphasized that there are no stability guarantees on the Plugin API (yet)
Also, we don’t have to remove it in 2.31 just because we said we would
but I did want to light a fire under plugin authors
w
That's a weird failure - how did we update a dependency to ahead of what's released on npm? https://www.npmjs.com/package/mobx-react-lite The 4.1.1 changelog was created 5 hours ago
Copy code
pants.engine.process.ProcessExecutionFailure: Process 'Run redocly on 1 file.' failed with exit code 1.
stdout:

stderr:
npm error code ETARGET
npm error notarget No matching version found for mobx-react-lite@^4.1.1.
npm error notarget In most cases you or one of your dependencies are requesting
npm error notarget a package version that doesn't exist.
npm error A complete log of this run can be found in: ._npm/_logs/2025-09-26T15_21_04_560Z-debug-0.log
I would bet we're pulling down an un-locked package.json or something crazy like that
https://github.com/mobxjs/mobx/issues/4585 This is everyone suffering from that failed package update
c
:-( If someone knows anything about javascript could take that one I'd be obliged
w
I think it's redocly - (currently hypothesis - won't have time to be sure until this evening). it's the fact that we're using a tool that doesn't seem to have a package lock - so it gets downloaded, and whatever the latest patch is gets used, and that 4.1.1 had a failed update to npm according to their github actions. What I don't understand is how "something" was notified to update the local deps
Its' the dependency we use causing it: https://github.com/Redocly/redocly-cli/issues/2332
h
My JS is weak
but I’ll see if I can poke at it
w
Not sure what we can do right now - the NPM package needs to be pushed correctly. Maybe we can downgrade our redocly, but if they don't lock their JSON then it doesn't matter. I don't know if our js backend lets us specify a lock file for a NodeTool
Oh, we can create a resolve for it maybe? And then 
install from resolve
h
This is all outside my area
w
Yeah, I don't know what redocly is - but the lack of lockfile is weird - maybe I'm missing it
I have to refresh myself on how npm workspaces work - like, if that lock is transitive. Either way, something is whack
h
I wouldn’t even be refreshing, I’d be learning from scratch
w
I can look into it in the evening
h
So is the short-term solution (for now) to hope that the owner of that package re-publishes it?
w
Skip the test
The github issue implied they would be looking into it next week, in case "it" means republishing for older releases (and ours is pretty old)
My initial plan was predicated on being able to install it locally, and creating a lock - but the flaw in that is that I can't download it - need to patch it... Blah
So, this package.json will work - and it will create a 
package-lock.json
- if we can force the redocly subsystem to use that lockfile, it should be fine
Copy code
{
  "name": "1",
  "version": "1.0.0",
  "description": "",
  "license": "ISC",
  "author": "",
  "type": "commonjs",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@redocly/cli": "1.10.5"
  },
  "overrides": {
    "@redocly/cli": {
      "mobx-react-lite": "4.1.0"
    }
  }
}
WHether it works at runtime 🤷
package-lock.json
Okay, this turned into a complete debacle. Also, it turns out that you can't just skip tests due to a forbidden skipped test error
h
You have to add a second allow-skipping annotation
(which I think we should get rid of, seems a bit pointless to me)
w
Yeah, I think skipping/non-skipping should be more related to PRs rather than annotation stacking
https://github.com/mobxjs/mobx/issues/4585 Supposedly the offending package has been installed - still weird that a package failing to deploy would cause anything to break - since NPM didn't have it yet. But someone had a bad dependency somewhere. Still need a lockfile, but I kicked off the failed builds to see if they pass now
🙏 1
6 Views
Open in Slack
PreviousNext
Powered by