Version 2.0 Discussion

[yagni]

There are a couple of issues in the backlog that require a major version bump and could be beneficial, so I thought I'd get that process started. I created a milestone and added the issues there.

This issue is for discussion around 2.0 itself. Please discuss issue-specific details in the issues themselves.

@chafey @swederik @dannyrb @galelis (and anyone else) want to weigh in on what should/shouldn't be included in 2.0?

[Ragnar-Oock]

I'm biased but maybe making the types more explicit (either by rewriting the lib in TS or by updating the type declaration like I proposed in #258 last year) would help when using the lib for advanced usage (i.e. not just throwing the file into cornerstone (legacy or 3d) for it to display the images on screen). The biggest pain point is the Element interface that has every possible element kinds merge into a single interface instead of the 4 different kinds that are actually returned by the parser (sequence elements, encapsulated PixelData element, FileMetaInformation element and the "basic" elements).
For an actual example use case I had to create a wrapper around dicom-parser to edit DICOM files (for anonymization mostly).

[sedghi]

The most important feature in Version 2.0 should be ES Modules, in my opinion.

We have to patch the modern bundlers because of dicomParser right now

import { viteCommonjs } from "@originjs/vite-plugin-commonjs"


export default defineConfig({
  plugins: [viteCommonjs()],
  optimizeDeps: {
    include: ["dicom-parser"],
  },
})

[Ragnar-Oock]

I don't remember having encountered bundling issues when using dicon-parser, but I never had it on its own so it's possible that I fixed it alongside cornerstone legacy when I ussed it.
And I do agree the migration to ESM is more important than typing (at least assuming it doesn't degrade the existing types)

[Ragnar-Oock]

Are there any plans for this rework? I don't use dicom-parser myself anymore, but I have time to contribute to a rewrite (partial or not)

As a side note, has it been envisioned to provide DICOM writing capabilities to the cornerstone ecosystem? I don't think that should be part of dicom-parser necessarily (it would clash with the name), but being able to write DICOM files is a rather important feature when building DICOM-based applications. It would open the way for easy in-browser anonymization or file compression to platforms like Radiopeadia or Imaios's eCases, which allow users to share DICOM files.

[yagni]

I do still have plans for this; I'd like to do one more minor release of version 1 that has the ESM types and updates to latest webpack. You're welcome to start on any of the issues in version 2

[Ragnar-Oock]

updates to latest webpack

Have you looked at using vite instead of webpack ? As more and more of the ecosystem is moving to it. Not moving is totally valid though.

and is there plans to fold dicom-parser into the cornerstone monorepo in the future ?

[sedghi]

I'm voting against Vite, as it's a bundler for applications, not libraries. The current standard is either Rollup, the new Rolldown (though it's not mature yet), or Webpack. I think Rollup is good enough, although I really wish Rolldown was mature enough to use.

As for putting dicom-parser into the Cornerstone.js monorepo, that's not the plan just yet.

[Ragnar-Oock]

I'm going over the backlog listed in the README file and I noticed this line :

Figure out how to automatically generate documentation from the source (jsdoc)

I api-extractor on my projects to do this but it requires using typescript and a strict following of the syntax for things to work. So I wanted to ask : is there plans for the V2 to move to typescript for the source code or do you want to stick to JS + JSDoc only ? (which is a perfectly understandable standpoint)