Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[turborepo] Turbo error: unable to find any locator for string_decoder@0.1 #6232

Closed
robinelvin opened this issue Oct 20, 2023 · 3 comments · Fixed by #6296
Closed

[turborepo] Turbo error: unable to find any locator for string_decoder@0.1 #6232

robinelvin opened this issue Oct 20, 2023 · 3 comments · Fixed by #6296
Assignees
@chris-olszewski
Labels
kind: bug Something isn't working

Comments

@robinelvin
Copy link

robinelvin commented Oct 20, 2023 •
edited
Loading

What version of Turborepo are you using?

1.10.16

What package manager are you using / does the bug impact?

Yarn v2/v3 (node_modules linker only)

What operating system are you using?

Mac

Describe the Bug

Running yarn turbo prune on one of my projects in a monorepo results in some (all?) files being produced in out but the command fails with: Turbo error: unable to find any locator for string_decoder@0.1

Running yarn why string_decoder@0.1 comes back with nothing and yarn why string_decoder shows a lot of different versions none of which are 0.1

yarn why string_decoder
├─ raw-body@npm:1.1.7
│  └─ string_decoder@npm:0.10.31 (via npm:0.10)
│
├─ readable-stream@npm:2.3.7
│  └─ string_decoder@npm:1.1.1 (via npm:~1.1.1)
│
├─ readable-stream@npm:2.3.8
│  └─ string_decoder@npm:1.1.1 (via npm:~1.1.1)
│
├─ readable-stream@npm:3.6.2
│  └─ string_decoder@npm:1.3.0 (via npm:^1.1.1)
│
└─ readable-stream@npm:4.4.2
   └─ string_decoder@npm:1.3.0 (via npm:^1.3.0)

I have removed node_modules and yarn.lock and reinstalled and still get the same issue. Yarn itself never complains and my builds all work.

Expected Behavior

The command should work

To Reproduce

I'm unable to find how to reproduce this as filtering by another scope in my monorepo works fine. This seems to be related to a particular scope.

Reproduction Repo

No response
@robinelvin robinelvin added kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage owned-by: turborepo labels Oct 20, 2023
@chris-olszewski
Copy link
Member

chris-olszewski commented Oct 23, 2023 •
edited
Loading

Could you provide your lockfile? (Either here or privately share a copy with me via a private repository)

If you're unable to, then providing the entry in yarn.lock for raw-body and string_decoder@npm:0.10.31

@chris-olszewski chris-olszewski self-assigned this Oct 23, 2023
@robinelvin
Copy link
Author

Here you go:

"raw-body@npm:~1.1.0":
  version: 1.1.7
  resolution: "raw-body@npm:1.1.7"
  dependencies:
    bytes: 1
    string_decoder: 0.10
  checksum: 75ab1815ac54992abccccdffb27bd9ad9f5b6f5fb66e740474ad0d1bd3c1425e407b2be5eb34e0bef3da2c66bfa6a2c2b77498596f5b9999ead2d449fff0226f
  languageName: node
  linkType: hard

"string_decoder@npm:0.10":
  version: 0.10.31
  resolution: "string_decoder@npm:0.10.31"
  checksum: fe00f8e303647e5db919948ccb5ce0da7dea209ab54702894dd0c664edd98e5d4df4b80d6fabf7b9e92b237359d21136c95bf068b2f7760b772ca974ba970202
  languageName: node
  linkType: hard

Full file: yarn.lock

I wonder if it's something as simple as Turbo parsing the 0.10 as 0.1....

@chris-olszewski chris-olszewski mentioned this issue Oct 24, 2023
Closed
@chris-olszewski
Copy link
Member

It seems this is an underlying issue with our YAML parsing library: dtolnay/serde-yaml#165 (comment)

Continuing to look into either an upstream fix or a workaround

@chris-olszewski chris-olszewski mentioned this issue Oct 26, 2023
Merged
@chris-olszewski chris-olszewski removed the needs: triage New issues get this label. Remove it after triage label Oct 27, 2023
chris-olszewski added a commit that referenced this issue Oct 30, 2023
@chris-olszewski
fix(lockfiles) trailing zero yaml parse (#6296)
8af1b94 
### Description

Fixes #6232

This PR allows us to properly deserialize semver versions from YAML in
`yarn.lock`. Previously we would fail at parsing ranges with trailing
zeros e.g. `(0.10f32).to_string() == "0.1"`.

The approach taken in this PR is due to some outstanding quirks in
`serde_yaml`:
-
dtolnay/serde-yaml#165 (comment)
- dtolnay/serde-yaml#388
Our usage of `#[serde(flatten)]` in `LockfileData` caused attempting to
parse `2` or `0.10` as a `String` to fail. To avoid this we first parse
the document as a map with a union of the metadata/package entries and
then convert this to the expected structure. This provides us the type
safety of the old implementation, but at the cost of rebuilding the map.

As a minor thing, I removed all unused `Serialize`/`Deserialize`
implementations to make it clear which codepaths actually get used.

### Testing Instructions

Existing unit tests pass.

I changed out the old unit tests for `SemverString` to be captured by
the new `berry_semver.lock` test fixture which covers the same cases. We
do this because even if parsing versions works when invoked directly,
adding `#[serde(flatten)]`/`#[serde(untagged)]` to any containing
structure changes the behavior.


Closes TURBO-1540

---------

Co-authored-by: Chris Olszewski <Chris Olszewski>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@chris-olszewski chris-olszewski

Labels
kind: bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(lockfiles) trailing zero yaml parse vercel/turborepo
2 participants
@robinelvin @chris-olszewski