@playpilot/tpi 6.11.0 → 6.12.0

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/README.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # 💉 PlayPilot Link Injections
2
2
 
3
- Link Injections (also called TPI (Text Playlink Injection) and ALI (Article Link Injection)) adds links to any page content. These links open a popover or modal with relevant information for any given movie or show. Alternatively, they link directly to the related PlayPilot page.
3
+ Link Injections (also called TPI (Text Playlink Injection)) adds links to any page content. These links open a popover or modal with relevant information for any given movie or show. Alternatively, they link directly to the related PlayPilot page. This also contains the Streaming Guide all under one script. TPI and the Streaming Guide are tightly linked as they share many components.
4
4
 
5
5
  ## Development
6
6
 
@@ -13,13 +13,28 @@ The dev environment will be available at:
13
13
  ```
14
14
  localhost:3000
15
15
  ```
16
- Only the root page has content. This page contains multiple examples different injection scenarios, some real, some made up. Some of these are intentionally tricky to parse, but have come up as real examples in the past.
16
+ The root page contains a test article with various real-world scenarios that are tricky to inject in to. The primary `+layout.svelte` file confusingly contains the actual content for this page. This is because the `+page.svelte` file is what is eventually build into the final script, ignoring anything in the +layout file.
17
+ `/elements` Contains various elements to help during debugging such as modals, popovers, and some streaming guide components, as well as some other individual components for titles.
18
+ `/explore` Contains the streaming guide.
19
+
20
+ The final script is build including the `main.ts` or `mount.ts` entry files. These do not run when running `npm run dev`. To work on these files you can instead run:
21
+ ```
22
+ npm run dev-build
23
+ ```
24
+ and visit the dev environment at:
25
+ ```
26
+ localhost:3000/build.html
27
+ ```
28
+ This does currently not feature any HMR or other fancy-ness. It's just an HTML file.
17
29
 
18
30
  ## Build
19
31
 
20
32
  To build the final script simply run `npm run build`.
21
33
 
22
- The final build differs largely from the development environment. The development environment uses SvelteKit, but the final build only uses Svelte which is build to a single file that includes all images, css, and of course the javascript itself. This file is output to `/dist/link-injections.js`. This file is included in the repo.
34
+ The final build differs largely from the development environment. The development environment uses SvelteKit, but the final build only uses Svelte which is build to distrinct files:
35
+ - `dist/link-injections.js`. This is the primary entry point and should be as light as possible. Svelte is not used here. This fetches the domain config file, and if that is in order it will fetch injections along side the next script.
36
+ - `dist/mount.js`. This contains everything needed for both TPI and the Streaming Guide. All Svelte components including their CSS are bundled in this one file.
37
+ - `dist/editorial.mount.js`. This contains the same as `dist/mount.js` plus everything needed for the editorial mode, which are the editorial components themselves. Whether this file or `mount.js` are loaded are determined by `dist/link-injections.js` based on the existence of a URL param or an auth cookie.
23
38
 
24
39
  ## Publishing
25
40
 
@@ -31,6 +46,8 @@ The build and publish a new version simply run:
31
46
  npm run release major|minor|patch
32
47
  ```
33
48
 
49
+ Before doing this you might want to make sure you are logged in to NPM by running `npm login`.
50
+
34
51
  To publish the script manually follow these steps (this is often done for beta versions):
35
52
  1. Build the script using `npm run build, optionally commit the new file as a separate commit
36
53
  2. Bump the package.json version, optionally commit this change
@@ -43,6 +60,6 @@ The script inserts elements right on the page it is used, because of that all el
43
60
 
44
61
  - **Avoid semantics tags.** Tags such as `h1`, `header`, `p`, and more, are convenient but are very likely to be styled quite specifically. Instead, stick to general elements such as `div` and `span`, but with proper attributes. A heading might use `div role=heading level=2`, a dialog might use `div role=dialog`. While this doesn't do anything visually, it keeps accessibility features intact.
45
62
  - **Do not use global styling.**. Styling from the page leaks into element from our script, but the opposit is also true. Any global styling we apply will apply to the page itself. Stick to scoped styling either via styling in Svelte components, or stick to very specific class names either on the elements themselves or as parents. `src/lib/scss/global.scss holds such elements. Some other global css in included in `src/routes/+page.svelte`
46
- - **Use css variables for styling.** All elements that are displayed on the page might need to be styled to match the page. This is done through css variables rather than just overwriting style via selectors. This makes it easier for us to change styling without having to worry about updating partner specific styling. These css variables often have other css variables as fallbacks, and are always prefixed with --playpilot. For instance `var(--playpilot-dialog-background, var(--playpilot-light))`. This can be further expanded to `var(--playpilot-title-background, var(--playpilot-dialog-background, var(--playpilot-light)))`. In this case all default styling is still handled through our own styling `--playpilot-light`, but can be overwritten on all relevant elements with `--playpilot-dialog-background`, and more specifically with `--playpilot-title-background`.
63
+ - **Use css variables for styling.** All elements that are displayed on the page might need to be styled to match the page. This is done through css variables rather than just overwriting style via selectors. This makes it easier for us to change styling without having to worry about updating partner specific styling. These css variables often have other css variables as fallbacks, and are always prefixed with --playpilot. For instance `var(--playpilot-dialog-background, var(--playpilot-light))`. This can be further expanded to `var(--playpilot-title-background, var(--playpilot-dialog-background, var(--playpilot-light)))`. In this case all default styling is still handled through our own styling `--playpilot-light`, but can be overwritten on all relevant elements with `--playpilot-dialog-background`, and more specifically with `--playpilot-title-background`. To make this process easier, use the `theme` SCSS helper function. This will output a css variable with a default. The `--playpilot-` prefix is automatically added. `theme(title-background, #ff0000)`;
47
64
  - **Avoid external libraries.** The script is meant to be as lean as possible, it needs to load quickly. External libraries by nature contain things we don't need and add unnecessary bloat. That's not always true, so use your best judgement. This only includes libraries that would be included in the final build of course.
48
65
  - **Do not use non-vector images within the script.** The script is compiled to a single file. Including non-vector images will lead to a much larger file size as these images will need to be inlined and this is not compressable. Stick to SVGs and make sure these SVGs are inlined.