cc @nex3

I believe CI was failing because I missed adding a link to the dart-sass changes. That should now be resolved.

I'm a bit confused about where the CI failure is coming from. Is there a place I'm missing updating? All relevant code touching Value should have an associated assertMixin method, and I'm linking to all relevant PRs in the PR description.

Maybe we need to add a mixin.d.ts to https://github.com/sass/sass/tree/main/js-api-doc/value ?

I made the change in sass/sass#3674, but CI fails there I believe because the spec file is in the accepted/ folder and not spec/.

The spec failure is due to the mismatch between js-api-doc/ and spec/js-api/. They need to be modified at the same time to mirror the change.

Is the file in the spec/js-api not auto-generated?

Is the file in the spec/js-api not auto-generated?

As for as I know they are not auto-generated, therefore the CI has a check to ensure the documentation matches the spec.

I got CI passing on the sass/sass PR if someone is able to re-run the CI for this PR

The JS API steps seem to pass now, but the static analysis step is failing with an error that looks unrelated to my changes. Is the failure spurious?

The JS API steps seem to pass now, but the static analysis step is failing with an error that looks unrelated to my changes. Is the failure spurious?

Because this repository does not have package-lock.json checked in, the issue could be that one of the lint related dependency got a new version and it is breaking the test. For now I guess we will have to debug and find out what went wrong.

In the future, for more stable and reproducible CI runs I think we could check in package-lock.json and use npm ci instead of npm install in tests. The only downside is that dependabot will be noisier about each dependency update, but on the upside this actually give us better test coverage for dependency version changes.

#255 should fix the static analysis issues.