Sebastian Schuberth

> I've tested it as well by using two evaluation-result.json files and comparing old vs. new report. Thanks for the effort you've put into testing this!

> I debugged the filtering issue and it bug in upstream Ant Design Could you please link the upstream issue (or create one if none exists yet) so we can...

> publish the JS build as an NPM package Sure, that would be the plan.

> > > do a _one-time_ conversion of the SPDX grammar > > > > > > @mnonnenmacher, would that approach work for you? > > Yes, that would be...

> Would it be useful if such runtime was packaged as an NPM package? I guess it would, yes.

> In that context it could make sense to split the module into two separate modules I agree. Porting our SPDX document support to kotlinx.serialization could make sense nonetheless.

Is in this case `node-bin-setup` just a (non-platform-specific) alias for a platform-specific package (`node-linux-x64` in your case)?

> Is in this case `node-bin-setup` just a (non-platform-specific) alias for a platform-specific package (`node-linux-x64` in your case)? Ping @fviernau! And is this still valid after all the dependency graph...

@fviernau, do we want to keep this open for investigation at some point in time, or should we close it and only reopen if we come across the issue again?

Could be the related to https://github.com/oss-review-toolkit/ort/issues/6239.