carta-frontend 5.0.0-dev → 5.0.0

package/docs_website/docs/code-snippet-tutorial/image-fitting.mdx

@@ -15,12 +15,15 @@ const file = await app.openFile("[filename]");
 // Display the fitting widget
 app.dialogStore.showDialog("fitting-dialog");
 
-// Clear previous inputs of initial values
-app.imageFittingStore.clearComponents();
-
-// Set initial values
+// Set the number of Gaussian components
 app.imageFittingStore.setComponents(2);
 
+// Option 1: Fit the image with auto generated initial values
+app.imageFittingStore.fitImage();
+
+// Option 2: Fit the image without auto generated initial values
+app.imageFittingStore.setIsAutoInitVal(false);
+
 const component1 = app.imageFittingStore.components[0];
 component1.setCenterX(128);
 component1.setCenterY(129);
@@ -37,6 +40,5 @@ component2.setFwhmX(4);
 component2.setFwhmY(9);
 component2.setPa(40);
 
-// Fit the image
 app.imageFittingStore.fitImage();
 ```

package/docs_website/docs/code-snippet-tutorial/quick-start.mdx

@@ -79,4 +79,4 @@ app.closeFile(file1, false); // No user confirmation
 app.closeOtherFiles(file2);
 ```
 
-For all functions and objects availble in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.
+For all functions and objects available in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.

package/docs_website/docs/code-snippet-tutorial/regions.mdx

@@ -14,7 +14,7 @@ const file = await app.openFile("my_image.fits");
 
 ## Creating regions
 
-Regions on a specific image is accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
+Regions on a specific image are accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
 
 ```javascript
 console.log(file.regionSet.regions); // View all regions

package/docs_website/docs/contributing/github-workflow.md

@@ -10,7 +10,7 @@ The workflow for contributing to the codebase.
 
 When creating new issues, please refer to [this page](https://github.com/CARTAvis/carta-frontend/labels) for the available labels that can be added.
 
-If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resloving issues. Additionally, including testing images can be helpful for reproducing the issue.
+If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resolving issues. Additionally, including testing images can be helpful for reproducing the issue.
 
 ## Contributing to the codebase
 
@@ -53,7 +53,7 @@ git push
 
 #### Pull request template
 
-When making a pull request from you branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
+When making a pull request from your branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
 
 In the description section, please provide details about your changes, including linked issues and companion pull requests (if there are), what is implemented or fixed, and how to test it.
 
@@ -117,7 +117,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 2. Check out the frontend branch:
 
     ```
-    git checkout "[the frontend branch]"
+    git checkout [the frontend branch]
     ```
 
 3. Check out the dev branch of the protobuf submodule and pull the latest version:
@@ -132,7 +132,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 4. Commit and push the changes:
 
     ```
-    git merge -a -m "update protobuf"
+    git commit -a -m "update protobuf"
     git push
     ```
 

package/docs_website/docs/contributing/release-guidelines.md

@@ -10,29 +10,29 @@ In this document, 123 is a placeholder for the current release number, and 124 f
 
 ### Beta release
 
-1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
+1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Create a `release/123.0` branch using the `dev` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-beta.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-beta.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. Create packages from the release branch.
 
 ### After beta release
 
 1. `dev` branch: update `CHANGELOG.md`. Create a new `Unreleased` section.
-2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.1`.
+2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.0`.
 
 ### Additional beta release
 
 This process should be followed if changes have to be made after the beta packages have already been published (or even provided to a limited number of users). If there are significant changes in `dev` that should _not_ be included in the beta release, follow the point release procedure instead (but adjust the version strings as required).
 
 1. Make the required fixes in `dev`.
-2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.2`.
+2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
 3. `dev` branch: update the user manual URL if necessary.
 4. Merge the `dev` branch into the `release/123.0` branch.
-5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.2`. Run `npm install` to update `package-lock.json`.
-6. Create a `v123.0.0-beta.2` tag using the release branch.
+5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
+6. Create a `v123.0.0-beta.1` tag using the release branch.
 7. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 8. Create packages from the release branch.
 
@@ -43,8 +43,8 @@ This process should be followed if changes have to be made after the beta packag
 1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Merge the `dev` branch into the `release/123.0` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-rc.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-rc.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. `release/123.0` branch: update the `package.json` version string to `123.0.0`. Run `npm install` to update `package-lock.json`.
 8. Create a `v123.0.0` tag using the release branch.

package/docs_website/versioned_docs/version-4.1.0/code-snippet-tutorial/quick-start.mdx

@@ -79,4 +79,4 @@ app.closeFile(file1, false); // No user confirmation
 app.closeOtherFiles(file2);
 ```
 
-For all functions and objects availble in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.
+For all functions and objects available in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.

package/docs_website/versioned_docs/version-4.1.0/code-snippet-tutorial/regions.mdx

@@ -14,7 +14,7 @@ const file = await app.openFile("my_image.fits");
 
 ## Creating regions
 
-Regions on a specific image is accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
+Regions on a specific image are accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
 
 ```javascript
 console.log(file.regionSet.regions); // View all regions

package/docs_website/versioned_docs/version-4.1.0/contributing/github-workflow.md

@@ -10,7 +10,7 @@ The workflow for contributing to the codebase.
 
 When creating new issues, please refer to [this page](https://github.com/CARTAvis/carta-frontend/labels) for the available labels that can be added.
 
-If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resloving issues. Additionally, including testing images can be helpful for reproducing the issue.
+If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resolving issues. Additionally, including testing images can be helpful for reproducing the issue.
 
 ## Contributing to the codebase
 
@@ -53,7 +53,7 @@ git push
 
 #### Pull request template
 
-When making a pull request from you branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
+When making a pull request from your branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
 
 In the description section, please provide details about your changes, including linked issues and companion pull requests (if there are), what is implemented or fixed, and how to test it.
 
@@ -117,7 +117,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 2. Check out the frontend branch:
 
     ```
-    git checkout "[the frontend branch]"
+    git checkout [the frontend branch]
     ```
 
 3. Check out the dev branch of the protobuf submodule and pull the latest version:
@@ -132,7 +132,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 4. Commit and push the changes:
 
     ```
-    git merge -a -m "update protobuf"
+    git commit -a -m "update protobuf"
     git push
     ```
 

package/docs_website/versioned_docs/version-4.1.0/contributing/release-guidelines.md

@@ -10,29 +10,29 @@ In this document, 123 is a placeholder for the current release number, and 124 f
 
 ### Beta release
 
-1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
+1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Create a `release/123.0` branch using the `dev` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-beta.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-beta.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. Create packages from the release branch.
 
 ### After beta release
 
 1. `dev` branch: update `CHANGELOG.md`. Create a new `Unreleased` section.
-2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.1`.
+2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.0`.
 
 ### Additional beta release
 
 This process should be followed if changes have to be made after the beta packages have already been published (or even provided to a limited number of users). If there are significant changes in `dev` that should _not_ be included in the beta release, follow the point release procedure instead (but adjust the version strings as required).
 
 1. Make the required fixes in `dev`.
-2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.2`.
+2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
 3. `dev` branch: update the user manual URL if necessary.
 4. Merge the `dev` branch into the `release/123.0` branch.
-5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.2`. Run `npm install` to update `package-lock.json`.
-6. Create a `v123.0.0-beta.2` tag using the release branch.
+5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
+6. Create a `v123.0.0-beta.1` tag using the release branch.
 7. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 8. Create packages from the release branch.
 
@@ -43,8 +43,8 @@ This process should be followed if changes have to be made after the beta packag
 1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Merge the `dev` branch into the `release/123.0` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-rc.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-rc.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. `release/123.0` branch: update the `package.json` version string to `123.0.0`. Run `npm install` to update `package-lock.json`.
 8. Create a `v123.0.0` tag using the release branch.

package/docs_website/versioned_docs/version-5.0.0-beta.1c/code-snippet-tutorial/quick-start.mdx

@@ -79,4 +79,4 @@ app.closeFile(file1, false); // No user confirmation
 app.closeOtherFiles(file2);
 ```
 
-For all functions and objects availble in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.
+For all functions and objects available in the <ApiLink path="/.-stores/class/AppStore">`app`</ApiLink> object, please refer to the <ApiLink path="/.-stores/class/AppStore">API documentation</ApiLink>.

package/docs_website/versioned_docs/version-5.0.0-beta.1c/code-snippet-tutorial/regions.mdx

@@ -14,7 +14,7 @@ const file = await app.openFile("my_image.fits");
 
 ## Creating regions
 
-Regions on a specific image is accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
+Regions on a specific image are accessible via <ApiLink path="/.-stores/class/RegionSetStore">`RegionSetStore`</ApiLink> under each image. Each region is represented by a <ApiLink path="/.-stores/class/RegionStore">`RegionStore`</ApiLink> object.
 
 ```javascript
 console.log(file.regionSet.regions); // View all regions

package/docs_website/versioned_docs/version-5.0.0-beta.1c/contributing/github-workflow.md

@@ -10,7 +10,7 @@ The workflow for contributing to the codebase.
 
 When creating new issues, please refer to [this page](https://github.com/CARTAvis/carta-frontend/labels) for the available labels that can be added.
 
-If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resloving issues. Additionally, including testing images can be helpful for reproducing the issue.
+If the issue is related to bug fixing, please use the [bug report template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/ISSUE_TEMPLATE/bug_report.md). Please make sure to fill in the template with all the necessary information, including the description, reproduction steps, and platform information. Providing reproduction steps is particularly helpful for resolving issues. Additionally, including testing images can be helpful for reproducing the issue.
 
 ## Contributing to the codebase
 
@@ -53,7 +53,7 @@ git push
 
 #### Pull request template
 
-When making a pull request from you branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
+When making a pull request from your branch, please use the [pull request template](https://github.com/CARTAvis/carta-frontend/blob/dev/.github/pull_request_template.md).
 
 In the description section, please provide details about your changes, including linked issues and companion pull requests (if there are), what is implemented or fixed, and how to test it.
 
@@ -117,7 +117,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 2. Check out the frontend branch:
 
     ```
-    git checkout "[the frontend branch]"
+    git checkout [the frontend branch]
     ```
 
 3. Check out the dev branch of the protobuf submodule and pull the latest version:
@@ -132,7 +132,7 @@ If the pull request requires changes in the carta-protobuf submodule and is read
 4. Commit and push the changes:
 
     ```
-    git merge -a -m "update protobuf"
+    git commit -a -m "update protobuf"
     git push
     ```
 

package/docs_website/versioned_docs/version-5.0.0-beta.1c/contributing/release-guidelines.md

@@ -10,29 +10,29 @@ In this document, 123 is a placeholder for the current release number, and 124 f
 
 ### Beta release
 
-1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
+1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Create a `release/123.0` branch using the `dev` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-beta.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-beta.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. Create packages from the release branch.
 
 ### After beta release
 
 1. `dev` branch: update `CHANGELOG.md`. Create a new `Unreleased` section.
-2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.1`.
+2. `dev` branch: update the documentation website ([guidelines](./documentation-guidelines/#Versioning)). Create a new version `123.0.0-beta.0`.
 
 ### Additional beta release
 
 This process should be followed if changes have to be made after the beta packages have already been published (or even provided to a limited number of users). If there are significant changes in `dev` that should _not_ be included in the beta release, follow the point release procedure instead (but adjust the version strings as required).
 
 1. Make the required fixes in `dev`.
-2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.2`.
+2. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0-beta.1`.
 3. `dev` branch: update the user manual URL if necessary.
 4. Merge the `dev` branch into the `release/123.0` branch.
-5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.2`. Run `npm install` to update `package-lock.json`.
-6. Create a `v123.0.0-beta.2` tag using the release branch.
+5. `release/123.0` branch: update the `package.json` version string to `123.0.0-beta.1`. Run `npm install` to update `package-lock.json`.
+6. Create a `v123.0.0-beta.1` tag using the release branch.
 7. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 8. Create packages from the release branch.
 
@@ -43,8 +43,8 @@ This process should be followed if changes have to be made after the beta packag
 1. `dev` branch: update `CHANGELOG.md`. Change the `Unreleased` heading to `123.0.0`.
 2. `dev` branch: update the user manual URL if necessary.
 3. Merge the `dev` branch into the `release/123.0` branch.
-4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.1`. Run `npm install` to update `package-lock.json`.
-5. Create a `v123.0.0-rc.1` tag using the release branch.
+4. `release/123.0` branch: update the `package.json` version string to `123.0.0-rc.0`. Run `npm install` to update `package-lock.json`.
+5. Create a `v123.0.0-rc.0` tag using the release branch.
 6. Test the release branch. Make any required fixes in the `dev` branch, and merge them into the release branch. Ideally, bump the version and create a new tag every time changes are merged. If you don't want to bump the version, remember to destroy and recreate the latest tag.
 7. `release/123.0` branch: update the `package.json` version string to `123.0.0`. Run `npm install` to update `package-lock.json`.
 8. Create a `v123.0.0` tag using the release branch.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "carta-frontend",
-    "version": "5.0.0-dev",
+    "version": "5.0.0",
     "repository": "https://github.com/CARTAvis/carta-frontend",
     "description": "The browser-based frontend component of CARTA, a radio-astronomy visualization tool designed for the ALMA, the VLA and the SKA pathfinders.",
     "homepage": "./",
@@ -88,9 +88,9 @@
         "analyze": "source-map-explorer build/static/js/main.*",
         "postinstall": "patch-package",
         "start": "npm run git-info; npm run strict-null-checks && react-scripts start",
-        "build": "npm run git-info; npm-run-all build-wrappers build-protobuf build-ts",
-        "build-docker": "npm run git-info; npm-run-all build-wrappers-docker build-protobuf build-ts",
-        "build-singularity": "npm run git-info; npm-run-all build-wrappers-singularity build-protobuf build-ts",
+        "build": "npm run git-info; npm-run-all build-wrappers build-protobuf link-schemas build-ts",
+        "build-docker": "npm run git-info; npm-run-all build-wrappers-docker build-protobuf link-schemas build-ts",
+        "build-singularity": "npm run git-info; npm-run-all build-wrappers-singularity build-protobuf link-schemas build-ts",
         "build-ts": "npm run strict-null-checks && react-scripts --max_old_space_size=4096 build",
         "build-libs": "./wasm_libs/build_libs.sh",
         "build-libs-docker": "./build_wasm_libs_docker.sh",
@@ -99,6 +99,7 @@
         "build-wrappers-docker": "./build_wasm_wrappers_docker.sh",
         "build-wrappers-singularity": "./build_wasm_wrappers_singularity.sh",
         "build-protobuf": "./protobuf/build_proto.sh",
+        "link-schemas": "./schemas/link_schemas.sh",
         "test": "react-scripts test --env=jsdom",
         "eject": "react-scripts eject",
         "reformat": "npx prettier --write ./src",

package/schemas/.github/workflows/AddToCartaVisProject.yml

@@ -0,0 +1,23 @@
+name: Add new issues and pull requests to CartaVis Board project
+
+on:
+  issues:
+    types:
+      - opened
+      - reopened
+  pull_request:
+    types:
+      - opened
+      - reopened
+
+jobs:
+  add-to-project:
+    name: Add issue to project
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/add-to-project@v0.6.1
+        with:
+          # You can target a project in a different organization
+          # to the issue
+          project-url: https://github.com/orgs/CARTAvis/projects/11
+          github-token: ${{ secrets.ADD_TO_CARTA_BOARD_PROJECT_PAT }}

package/schemas/.prettierrc.json

@@ -0,0 +1,18 @@
+{
+    "arrowParens": "avoid",
+    "bracketSpacing": false,
+    "embeddedLanguageFormatting": "auto",
+    "htmlWhitespaceSensitivity": "css",
+    "insertPragma": false,
+    "bracketSameLine": false,
+    "jsxSingleQuote": false,
+    "proseWrap": "preserve",
+    "quoteProps": "as-needed",
+    "requirePragma": false,
+    "semi": true,
+    "singleQuote": false,
+    "trailingComma": "none",
+    "useTabs": false,
+    "printWidth": 240,
+    "tabWidth": 4
+}

package/schemas/CMakeLists.txt

@@ -0,0 +1,15 @@
+ADD_EXECUTABLE(schemacompiler schemacompiler.c)
+FILE(GLOB SCHEMA_FILES CONFIGURE_DEPENDS "*_schema_*.json")
+
+FOREACH(INPUT_FILE ${SCHEMA_FILES})
+    CMAKE_PATH(GET INPUT_FILE FILENAME OUTPUT_FILE)
+    STRING(APPEND OUTPUT_FILE ".h")
+    ADD_CUSTOM_COMMAND(
+        OUTPUT ${OUTPUT_FILE}
+        DEPENDS schemacompiler ${INPUT_FILE}
+        COMMAND schemacompiler ${INPUT_FILE} ${OUTPUT_FILE}
+    )
+    LIST(APPEND SCHEMA_HEADERS ${OUTPUT_FILE})
+ENDFOREACH()
+
+ADD_LIBRARY(carta-schemas INTERFACE ${SCHEMA_HEADERS})

package/schemas/README.md

@@ -0,0 +1 @@
+This is a directory of JSON schemas used by CARTA components, published automatically from a [source repository](https://github.com/CARTAvis/schemas).

package/schemas/_config.yml

@@ -0,0 +1,7 @@
+exclude:
+  - CMakeLists.txt
+  - link_schemas.sh
+  - .prettierrc.json
+  - schemacompiler.c
+  - test
+  - .gitignore