You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add interlinearizer feature with XML parsing and web view integration (#6)
Add interlinear XML parser, minimal WebView integration, and full test coverage
- Parse PT9 interlinear XML (`fast-xml-parser`) into typed `InterlinearData`
- Public API in `interlinearizer.d.ts` (`StringRange`, `ClusterData`, `VerseData`, etc.)
- Register interlinearizer WebView provider and open React WebView on activation
- Document PT9 schema and parser behavior in `src/parsers/pt9-xml.md`
- Jest unit tests with 100% coverage on parsers, `main`, and web-view
- GitHub Actions workflow for test and lint on push/PR to main
- Handle `Excluded` flag and numeric/hash validation in parser
- Add test-data sample XML and PAPI mocks for tests
Copy file name to clipboardExpand all lines: README.md
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -90,21 +90,26 @@ Note: if you [update this extension from the template](#to-update-this-extension
90
90
91
91
The general file structure for an extension is as follows:
92
92
93
-
-`package.json`contains information about this extension's npm package. It is required for Platform.Bible to use the extension properly. It is copied into the build folder
93
+
-`package.json`(and `package-lock.json`) contain information about this extension's npm package and lockfile. They are required for Platform.Bible to use the extension properly. The lockfile is project-specific and is not synced from the template. The built extension is copied into the build folder
94
94
-`manifest.json` is the manifest file that defines the extension and important properties for Platform.Bible. It is copied into the build folder
95
95
-`src/` contains the source code for the extension
96
-
-`src/main.ts` is the main entry file for the extension
96
+
-`src/main.ts` is the main entry file for the extension (registers commands and wires interlinear XML)
97
97
-`src/types/interlinearizer.d.ts` is this extension's types file that defines how other extensions can use this extension through the `papi`. It is copied into the build folder
98
+
-`src/parsers/interlinearXmlParser.ts` parses interlinear XML into structured data (uses fast-xml-parser). The PT9 XML schema and parsed output are documented in `src/parsers/pt9-xml.md`
98
99
-`*.web-view.tsx` files will be treated as React WebViews
100
+
-`*.web-view.scss` files provide styles for WebViews
99
101
-`*.web-view.html` files are a conventional way to provide HTML WebViews (no special functionality)
102
+
-`src/__tests__/` contains unit tests (Jest) for the extension, including parser tests (valid and invalid XML, edge cases) and web-view tests
103
+
-`__mocks__/` contains Jest mocks for the PAPI, file modules, and test fixtures used by tests in `src/__tests__/`. The `@papi/backend` and `@papi/frontend` mocks are used mutually exclusively (backend for main.ts tests, frontend for WebView tests); each mock file ends with `export {}` so TypeScript treats it as a module.
100
104
-`assets/` contains asset files the extension and its WebViews can retrieve using the `papi-extension:` protocol, as well as textual descriptions in various languages. It is copied into the build folder
101
105
-`assets/displayData.json` contains (optionally) a path to the extension's icon file as well as text for the extension's display name, short summary, and path to the full description file
102
106
-`assets/descriptions/` contains textual descriptions of the extension in various languages
103
107
-`assets/descriptions/description-<locale>.md` contains a brief description of the extension in the language specified by `<locale>`
104
108
-`contributions/` contains JSON files the platform uses to extend data structures for things like menus and settings. The JSON files are referenced from the manifest
105
109
-`public/` contains other static files that are copied into the build folder
110
+
-`test-data/` contains sample interlinear XML (e.g. `Interlinear_en_MAT.xml`) for development and tests
106
111
-`.github/` contains files to facilitate integration with GitHub
107
-
-`.github/workflows` contains [GitHub Actions](https://github.com/features/actions) workflows for automating various processes in this repo
112
+
-`.github/workflows` contains [GitHub Actions](https://github.com/features/actions) workflows for automating various processes in this repo (e.g. **Test** and **Lint** on push/PR to main, release-prep, hotfix-\*; **Publish** and **Bump Versions** manual dispatch; **CodeQL** for security)
108
113
-`.github/assets/release-body.md` combined with a generated changelog becomes the body of [releases published using GitHub Actions](#publishing)
109
114
-`dist/` is a generated folder containing the built extension files
110
115
-`release/` is a generated folder containing a zip of the built extension files
@@ -155,7 +160,6 @@ These steps will walk you through releasing a version on GitHub and bumping the
155
160
1. Make sure the versions in this repo are on the version number you want to release. If they are not, manually dispatch the [Bump Versions workflow](#bumping-version-without-publishing-a-release) or run the `bump-versions` npm script to set the versions to what you want to release on the branch you want to release from.
156
161
157
162
2. Manually dispatch the Publish workflow in GitHub Actions targeting the branch you want to release from. This workflow creates a new pre-release for the version you intend to release and creates a new `bump-versions-<next_version>` branch to bump the version after the release so future changes apply to a new in-progress version instead of to the already released version. This workflow has the following inputs:
158
-
159
163
-`version`: Enter the version you intend to publish (e.g. 0.2.0). This is simply for verification to make sure you release the code that you intend to release. It is compared to the version in the code, and the workflow will fail if they do not match.
160
164
-`newVersionAfterPublishing`: Enter the version you want to bump to after releasing (e.g. 0.3.0-alpha.0). Future changes will apply to this new version instead of to the version that was already released. Leave blank if you don't want to bump.
161
165
-`bumpRef`: Enter the Git ref you want to create the bump versions branch from, e.g. `main`. Leave blank if you want to use the branch selected for the workflow run. For example, if you release from a stable branch named `release-prep`, you may want to bump the version on `main` so future development work happens on the new version, then you can rebase `release-prep` onto `main` when you are ready to start preparing the next stable release.
0 commit comments