Deprecate

BREAKING_CHANGES.md

@@ -10,6 +10,28 @@ For a log and guide when transitioning from itk.js to itk-wasm,
 please see [the migration
 guide](doc/content/docs/itk_js_to_itk_wasm_migration_guide.md).
 
+## From 1.0.0-b.158 to 1.0.0-b.159
+
+- itkConfig.js as been replaced by run-time configuration via setPipelineWorkerUrl, setPipelinesBaseUrl
+- readDICOMTags has been migrated to @itk-wasm/dicom and as readDicomTags
+- readDICOMTagsArrayBuffer has been migrated to @itk-wasm/dicom and as readDicomTags
+- readDICOMTagsLocalFile has been migrated to @itk-wasm/dicom and as readDicomTagsNode
+- readImageDICOMFileSeries has been migrated to @itk-wasm/dicom as readImageDicomFileSeries
+- readImageDICOMArrayBufferSeries has been migrated to @itk-wasm/dicom as readImageDicomFileSeries
+- readImageLocalDICOMFileSeries has been migrated to @itk-wasm/dicom as readImageDicomFileSeriesNode
+- meshToPolyData, meshToPolyDataNode, polyDataToMesh, polyDataToMeshNode have been migrated to @itk-wasm/mesh-to-poly-data
+- High level IO function have been removed: readArrayBuffer, readBlob, readFile, readLocalFile, writeLocalFile
+- readImageArrayBuffer has been migrated to @itk-wasm/image-io as readImageFile
+- readImageBlob has been migrated to @itk-wasm/image-io as readImageFile
+- readImageFile has been migrated to @itk-wasm/image-io as readImageFile
+- readImageFileSeries has been migrated to @itk-wasm/image-io readImageFileSeries
+- readImageLocalFile has been migrated to @itk-wasm/image-io readImageFileNode
+- readMeshArrayBuffer has been migrated to @itk-wasm/mesh-io readMeshFile
+- readMeshFile has been migrated to @itk-wasm/mesh-io readMeshFile
+- readMeshLocalFile has been migrated to @itk-wasm/mesh-io readMeshFileNode
+- writeImageArrayBuffer has been migrated to @itk-wasm/image-io writeImageFile
+- writeImageLocalFile has been migrated from @itk-wasm/image-io writeImageFileNode
+
 ## From 1.0.0-b.101 to 1.0.0-b.102
 
 - apply-presentation-state-to-dicom-image does not take dicom image out flag: was not supported

docs/development/itk_js_to_itk_wasm_migration_guide.md

@@ -1,10 +1,10 @@
-# Migration Guide: From itk.js to itk-wasm
+# Migration Guide: From itk.js to ITK-Wasm
 
-*Note: itk-wasm is currently in the beta development stage. The interface is relatively stable while functionality is currently being fleshed out. Updates for the rest of the documentation for changes from itk.js to itk-wasm is in progress. Last updated August 5th, 2023.*
+*Note: ITK-Wasm is currently in the beta development stage. The interface is relatively stable while functionality is currently being fleshed out. Updates for the rest of the documentation for changes from itk.js to ITK-Wasm is in progress. Last updated December 14th, 2023.*
 
-**itk-wasm** is a major upgrade with a focus on universal, performant computing in WebAssembly. The itk.js to itk-wasm transition also brings improvements, including modern, elegant programming interfaces, accelerated performance, and execution beyond JavaScript thanks to [WASI](https://wasi.dev).
+**ITK-Wasm** is a major upgrade with a focus on universal, performant computing in WebAssembly. The itk.js to ITK-Wasm transition also brings improvements, including modern, elegant programming interfaces, accelerated performance, and execution beyond JavaScript thanks to [WASI](https://wasi.dev).
 
-Most itk.js client code will simply need to update its import statements to leverage itk-wasm. However, there are also other more advanced changes. A description of the changes, their motivation, and example migration code can be found below.
+Most itk.js client code will simply need to update its import statements to leverage ITK-Wasm. However, there are also other more advanced changes. A description of the changes, their motivation, and example migration code can be found below.
 
 ## Module import statements
 
@@ -37,57 +37,103 @@ import { IntTypes } from 'itk-wasm'
 
 ## TypeScript support
 
-Typescript support was added, but, of course, you can still just use JavaScript if you wish. In itk-wasm, adoption of modern JavaScript constructs was extended, e.g. classes.
+Typescript support was added, but, of course, you can still just use JavaScript if you wish. In ITK-Wasm, adoption of modern JavaScript constructs was extended, e.g. classes.
 
 ## Bundlers
 
-ECMAScript Module (ESM) support was improved.
+ECMAScript Module (ESM) support is now standard.
 
 There is now an improved approach for web workers for bundlers, CORS constraints.
 
+## itkConfig.js removed
+
+The `itkConfig.js` module in itk-js and initial versions of ITK-Wasm specified where to look for the io webassembly modules and an optional default base URL for pipeline modules.
+
+This build-time approach has been replaced by a run-time configuration approach, which is much easier to specify and works transparently in a nested dependency situation.
+
+There are now only two configuration settings.
+
+1. The location of the web worker module.
+2. The location of wasm module assets.
+
+### Specification of the web worker module location
+
+By default, the web worker module will be picked up by modern bundlers like Vite or WebPack without additional configuration, and the bundler will manage the location of and deployment of the bundle in a application build.
+
+ITK-Wasm packages also contain module bundle that embed the web workers.
+
+Finally, on an individual ITK-Wasm package scope or bundle scope via the `itk-wasm` package, the web worker can be vendored and its location at specified at runtime via `setPipelineWorkerUrl`.
+
+### Specification of the wasm asset location
+
+Previously, separate wasm asset locations were configured for io modules and general pipelines. Now, there is a single wasm asset configuration. It can be set on a per-package level or a common configuration for a bundle can be set.
+
+By default, the wasm asset location is configured to use the [JsDelivr](https://www.jsdelivr.com/) CDN for a package.
+
+On an individual ITK-Wasm package scope or bundle scope via the `itk-wasm` package, wasm assets can be vendored and their location specified at runtime via `setPipelinesBaseUrl`.
+
 ## IO modules are available in separate packages.
 
 IO modules are now installed in separate npm packages to limit the `itk-wasm` package size. You can install only the packages that you need.
 
-The version of these packages follow the `itk-wasm` package version and should be kept in sync. The io packages are:
+The io packages are:
 
-1. `itk-image-io`
-2. `itk-mesh-io`
+1. `@itk-wasm/image-io`
+2. `@itk-wasm/mesh-io`
 3. `@itk-wasm/dicom`
 
-An example that vendors these package's webassembly assets into an application for deployment can be found in the [Webpack Example](https://github.com/InsightSoftwareConsortium/itk-wasm/tree/main/examples/Webpack).
+An example that vendors these package's webassembly assets into an application for deployment can be found in the [Vite-based test applcation configuration](https://github.com/InsightSoftwareConsortium/itk-wasm/blob/main/packages/mesh-io/typescript/vite.config.js).
 
 ### DICOM image IO functions
 
 The following DICOM image IO functions have been migrated to the `@itk-wasm/dicom` package. Their interface changed in some cases.
 
 1. `readImageLocalDICOMFileSeries` -> `readImageDicomFileSeriesNode`
-1. `readImageDICOMFileSeries` -> `readImageDicomFileSeries`
-1. `readImageDICOMArrayBufferSeries` -> `readImageDicomFileSeries`
-1. `readDICOMTags` -> `readDicomTags`
-1. `readDICOMTagsArrayBuffer` -> `readDicomTags`
-1. `readDICOMTagsLocalFile` -> `readDicomTagsNode`
+2. `readImageDICOMFileSeries` -> `readImageDicomFileSeries`
+3. `readImageDICOMArrayBufferSeries` -> `readImageDicomFileSeries`
+4. `readDICOMTags` -> `readDicomTags`
+5. `readDICOMTagsArrayBuffer` -> `readDicomTags`
+6. `readDICOMTagsLocalFile` -> `readDicomTagsNode`
 
-## itkConfig.js content and usage
+### Migrated image-io and mesh-io functions
 
-The `itkConfig.js` specifies where to look for the io webassembly modules and an optional default base URL for pipeline modules.
+The following image and mesh IO functions have been migrated to the `@itk-wasm/image-io`
+and `@itk-wasm/mesh-io` package. Their interface changed in some cases.
 
-The default `itkConfig.js` is configured to use the [JsDelivr](https://www.jsdelivr.com/) CDN, but you may want to override this default.
+1. `readImageArrayBuffer` -> `readImageFile`
+2. `readImageBlob` -> `readImageFile`
+3. `readImageFileSeries` -> `readImageFileSeries`
+4. `readImageHTTP` -> `readImageHttp`
+5. `readImageLocalFile` -> `readImageNode`
+6. `readMeshArrayBuffer` -> `readMeshFile`
+7. `readMeshBlob` -> `readMeshFile`
+8. `readMeshLocalFile` -> `readMeshNode`
+9. `writeImageArrayBuffer` -> `writeImageFile`
+10. `writeImageLocalFile` -> `writeImageFileNode`
+11. `writeMeshArrayBuffer` -> `writeMeshFile`
+12. `writeMeshLocalFile` -> `writeMeshNode`
 
-In the [Webpack Example](https://github.com/InsightSoftwareConsortium/itk-wasm/tree/main/examples/Webpack) the io webassembly module assets are vendored into `/itk` directories, this module looks like:
+### MeshToPolyData
 
-```js
-const itkConfig = {
-  pipelineWorkerUrl: '/itk/web-workers/bundles/pipeline-worker.js',
-  imageIOUrl: '/itk/image-io',
-  meshIOUrl: '/itk/mesh-io',
-  pipelinesUrl: '/itk/pipelines',
-}
-
-export default itkConfig
-```
+The following mesh to polydata conversion functions have been migrated to the `@itk-wasm/mesh-to-poly-data` package.
+
+1. `meshToPolyData`
+2. `meshToPolyDataNode`
+3. `polyDataToMesh`
+4. `polyDataToMeshNode`
+
+### Removed high level IO functions
+
+The high level IO functions, that dealt with both images and meshes have been removed.
+
+These are:
 
-And it can be injected into an application bundle by setting defining `alias`'s to the configuration module for `../itkConfig.js` and `../../itkConfig.js`. For other override configuration options, see the [Webpack](https://github.com/InsightSoftwareConsortium/itk-wasm/tree/main/examples/Webpack) and Rollup (todo) examples.
+1. readArrayBuffer
+2. readBlob
+3. readFile
+4. readLocalFile
+5. writeArrayBuffer
+5. writeLocalFile
 
 ## CLI options
 
@@ -135,7 +181,7 @@ Support for the legacy GE image file formats, i.e. GE4, GE5, GEAdw, is no longer
 
 ## IOTypes
 
-The use of `IOTypes` in pipelines is deprecated and not expected to work in the future. These have been replaced by `InterfaceTypes`.
+The use of `IOTypes` in pipelines is deprecated has been removed. These have been replaced by `InterfaceTypes`.
 
 ## Argument order when writing image, mesh binaries
 

packages/core/typescript/itk-wasm/src/deprecated/index-common.ts

@@ -0,0 +1 @@
+// Common deprecated modules across browser and node.js

packages/core/typescript/itk-wasm/src/deprecated/index-node.ts

@@ -0,0 +1,20 @@
+import readDICOMTagsLocalFile from "./read-dicom-tags-local-file.js"
+export { readDICOMTagsLocalFile }
+
+import readImageLocalDICOMFileSeries from "./read-image-local-dicom-file-series.js"
+export { readImageLocalDICOMFileSeries }
+
+import meshToPolyDataNode from "./mesh-to-poly-data-node.js"
+export { meshToPolyDataNode }
+
+import polyDataToMeshNode from "./poly-data-to-mesh-node.js"
+export { polyDataToMeshNode }
+
+import readMeshLocalFile from "./read-mesh-local-file.js"
+export { readMeshLocalFile }
+
+import writeImageLocalFile from "./write-image-local-file.js"
+export { writeImageLocalFile }
+
+import readImageLocalFile from "./read-image-local-file.js"
+export { readImageLocalFile }