Skip to content

Version 1.93.3 causes Unsupported Platform error #404

Closed as not planned
Closed as not planned

Description

@jakehockey10

This package is being used by Angular and I'm running into an issue with the npm ci command with an error telling me that sass-embedded-all-unknown requires a platform that is NOT x64. If I add

  "overrides": {
    "sass-embedded": "1.93.2"
  }

to my package.json file, the error goes away. I'm not sure how to report this issue any better, as this is an indirect dependency. But I figured this was the right place to report the issue because downgrading to 1.93.2 immediately fixes the problem, which, to me, points to an issue with the latest release.

My project is a standard Angular CLI project, still on version 20 due to other libraries not happy with 21 yet.

Please let me know how I can provide any additional information that would be useful.

What led me to report here was the following output during diagnoses:

$ npm ls sass-embedded
fido@0.0.0 /home/jake/Code/kaizen-data-ventures/fido
├─┬ @angular/build@20.3.11
│ └─┬ vite@7.1.11
│   └── sass-embedded@1.93.3 deduped
├─┬ devextreme-themebuilder@25.1.6
│ └── sass-embedded@1.66.0
└── sass-embedded@1.93.3 extraneous

Activity

  1. ntkme commented on Nov 25, 2025

    @ntkme
    Contributor

    That package is for rare cpus like ppc64le etc, and your are not supposed to install it on x64. When you run npm install without a package-lock.json, this won’t happen. This is likely either a problematic lock file or a bug in npm. First, try delete the lock file and regenerate it. If you can still reproduce the error with a clean lock file, please open a bug against npm (or the package manager you’re using).

  2. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    I have definitely removed package-lock.json and node_modules many times in an effort to fix this. I've also changed what version of node and npm I'm using via nvm, and still running into this same issue.

  3. ntkme commented on Nov 25, 2025

    @ntkme
    Contributor

    Then it’s a bug in npm ci because it’s supposed to reproduce the previous npm install command. If npm install works, but npm ci doesn’t that’s clearly a bug in npm itself.

  4. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    Gotcha! I wish I knew enough about why that is an indication that it's clearly a bug with npm itself. I'm not quite sure I understand the difference between npm ci and npm install but it was suggested to me that I use npm ci in my ci pipelines and its been nothing but trouble for me since. I ALWAYS have to rebuild the lock file every time I commit a change to make npm ci happy.

  5. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    I'm not even sure how to report this to npm. But thank you for the clarification

  6. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    @ntkme Any idea why using a previous version using the package.json override seems to solve the problem? I've changed my ci pipelines to just use npm install instead of npm ci, but I'm still very curious why this only seems to be an issue with 1.93.3

  7. ntkme commented on Nov 25, 2025

    @ntkme
    Contributor

    Any idea why using a previous version using the package.json override seems to solve the problem? I've changed my ci pipelines to just use npm install instead of npm ci, but I'm still very curious why this only seems to be an issue with 1.93.3

    Because at the time we didn’t have this optional dependency with support for minor cpu architectures.

  8. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    So NPM is not handling the optional nature of this dependency correctly?

  9. ntkme commented on Nov 25, 2025

    @ntkme
    Contributor

    You can report bug at: https://github.com/npm/cli/issues

    And that summary is that npm ci should behave like npm install - that is to ignore optional dependencies for platforms that is not the current one, instead of throw an error.

    The whole idea of npm ci and lock file: because most npm packages use semver and we specify a range of versions that’s allowed to be installed. This creates a reproducibility issue that at different moments of time different latest versions might get installed, sometimes causing compatibility issues that’s hard to debug. The solution is lock file, which records how exactly the version range was resolved at a specific moment of time, and npm ci is supposed to replay the exact same resolution, so you will get exactly what you installed last time. - That’s the whole idea and that why npm install and npm ci works differently is a bug.

  10. jakehockey10 commented on Nov 25, 2025

    @jakehockey10
    Author

    Thank you for your time in explaining that to me in more detail. I appreciate you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions