expo-video-subtitle 0.1.2 → 0.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +9 -0
- package/FORK.md +28 -3
- package/README.md +14 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,15 @@ Changes inherited from the upstream base version are not repeated here — see t
|
|
|
7
7
|
[upstream changelog](https://github.com/expo/expo/blob/main/packages/expo-video/CHANGELOG.md)
|
|
8
8
|
for the history of everything that isn't subtitle related.
|
|
9
9
|
|
|
10
|
+
## 0.1.3
|
|
11
|
+
|
|
12
|
+
### Documentation
|
|
13
|
+
|
|
14
|
+
- Document how subtitles that are on screen at the same time are stacked, which shipped in 0.1.2 but
|
|
15
|
+
was only described in the changelog.
|
|
16
|
+
- Add a release procedure to `FORK.md`, including the rule that every version bump carries a
|
|
17
|
+
changelog entry.
|
|
18
|
+
|
|
10
19
|
## 0.1.2
|
|
11
20
|
|
|
12
21
|
### Fixed
|
package/FORK.md
CHANGED
|
@@ -61,7 +61,7 @@ Measured against the published `expo-video@56.1.4` tarball. `+`/`-` are added/re
|
|
|
61
61
|
|
|
62
62
|
> **This is the single most important thing to preserve.** If a sync re-introduces the `publication`
|
|
63
63
|
> block, `local-maven-repo/` or `prebuilds/`, the app keeps building — it just runs **upstream's**
|
|
64
|
-
> video module, and every subtitle feature silently disappears. Verify with §
|
|
64
|
+
> video module, and every subtitle feature silently disappears. Verify with §5.
|
|
65
65
|
|
|
66
66
|
### External API coupling to watch
|
|
67
67
|
|
|
@@ -107,7 +107,7 @@ Then re-apply the fork:
|
|
|
107
107
|
7. **Remove the Android `publication` block** from `expo-module.config.json`.
|
|
108
108
|
8. **Restore the fork's `package.json`** (§3) and keep `README.md`, `CHANGELOG.md`, `LICENSE`, `FORK.md`.
|
|
109
109
|
9. Update the baseline version in this file, the README, and add a `CHANGELOG.md` entry.
|
|
110
|
-
10. Verify with §
|
|
110
|
+
10. Verify with §5, then commit.
|
|
111
111
|
|
|
112
112
|
---
|
|
113
113
|
|
|
@@ -127,7 +127,32 @@ Upstream's `package.json` will overwrite these if copied blindly. Keep:
|
|
|
127
127
|
|
|
128
128
|
---
|
|
129
129
|
|
|
130
|
-
## 4.
|
|
130
|
+
## 4. Releasing
|
|
131
|
+
|
|
132
|
+
**Every version bump gets a `CHANGELOG.md` entry — no exceptions, including one-line fixes.**
|
|
133
|
+
The changelog is the only place a consumer can see what changed between two installs, and this
|
|
134
|
+
package ships native code, so a bump can silently change runtime behaviour on a device.
|
|
135
|
+
|
|
136
|
+
For each release:
|
|
137
|
+
|
|
138
|
+
1. Decide the version (semver against the *fork's* own API, not the upstream `expo-video` version):
|
|
139
|
+
- **patch** — bug fix, no API change.
|
|
140
|
+
- **minor** — new option/prop/field, or a behaviour change consumers may notice.
|
|
141
|
+
- **major** — anything that breaks an existing call site.
|
|
142
|
+
2. Add a `## <version>` section at the top of `CHANGELOG.md`, above the previous release, grouped
|
|
143
|
+
under `### Added` / `### Fixed` / `### Changed` / `### Documentation`. Write it for someone who
|
|
144
|
+
does not know the codebase: what they will observe, and on which platform. Say *why* when the
|
|
145
|
+
cause is non-obvious — the entries for 0.1.1 and 0.1.2 are the reference for the level of detail.
|
|
146
|
+
3. `npm version <version> --no-git-tag-version`.
|
|
147
|
+
4. Update the docs the change touches — `README.md` for anything user-facing (a new option, a
|
|
148
|
+
changed rendering behaviour), and §1 of this file if files were added, removed or newly modified.
|
|
149
|
+
5. Verify with §5, then commit and push.
|
|
150
|
+
6. `npm publish` (its `prepublishOnly` cleans and rebuilds; never publish from a dirty tree).
|
|
151
|
+
|
|
152
|
+
When a release syncs a new upstream `expo-video`, note the new baseline version in the changelog
|
|
153
|
+
entry, in §1 of this file and in the README's intro line.
|
|
154
|
+
|
|
155
|
+
## 5. Verification
|
|
131
156
|
|
|
132
157
|
Run all four. The native ones are what actually prove the fork survived the sync.
|
|
133
158
|
|
package/README.md
CHANGED
|
@@ -76,6 +76,20 @@ player.subtitleTrack = player.availableSubtitleTracks[0];
|
|
|
76
76
|
|
|
77
77
|
> **iOS limitations:** sideloading only runs on the asynchronous loading path (the default `VideoPlayer` constructor and `replaceAsync`, not the synchronous `replace`), and only for progressive (non-HLS, non-DRM) sources. HLS/DASH already carry their own subtitle renditions.
|
|
78
78
|
|
|
79
|
+
### Overlapping subtitles
|
|
80
|
+
|
|
81
|
+
Subtitle files often contain cues whose timestamps overlap — two speakers talking over each other, or
|
|
82
|
+
dialogue shown alongside on-screen text. Cues that are on screen at the same time are rendered as a
|
|
83
|
+
single stacked block, with the cue that started earliest at the bottom:
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
Apa mereka berdua berteman, ya? <- started later
|
|
87
|
+
Nah, ayo pergi. <- started earlier
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
This matches how WebVTT stacks cues, and behaves the same on Android and iOS. Cues that carry
|
|
91
|
+
explicit positioning (SubRip's `{\anN}` tags) are left where they were placed and are not merged.
|
|
92
|
+
|
|
79
93
|
## Styling subtitles
|
|
80
94
|
|
|
81
95
|
Pass a `subtitleStyle` prop to `VideoView`. It applies to whichever subtitle track is currently displayed, whether embedded or sideloaded. Colors accept a hex string (`#RGB`, `#RRGGBB`, `#RRGGBBAA`) or `transparent`.
|
package/package.json
CHANGED