ReadAlongs / Studio-Web

Suite of web packages for creating interactive ReadAlongs (this repo was formerly called Web-Component)
https://readalong-studio.mothertongues.org/
Other
10 stars 9 forks source link

fix(assets)!: get rid of useAssetsFolder boolean and replace with imageAssetsFolder string #243

Closed roedoejet closed 7 months ago

roedoejet commented 7 months ago

BREAKING CHANGE: useAssetsFolder is no longer valid.

The equivalent is imageAssetsFolder='assets/' which is the default.

It used to be that all readalong and audio files were forced to be in the same assets folder along with the images. Then we removed that requirement, and toggled the image assets as a boolean. But, we should really go one step further and define an imageAssetsFolder property on the readalong so that the .readalong file can just define image names and then prefix them with the imageAssetsFolder otherwise we'll be asking users to edit the .readalong file when they deploy their readalongs.

IMPORTANT NOTE: we need to publish v 1.2.0 to npm before merging this to main, otherwise the bundles that are downloaded from studio will incorrectly point to v1.1.0. Before merging this, please ping me to publish the new version on npm!

Also, I don't think the deploy preview will really work here for the bundle/single file html etc, since v1.2.0 won't be published to unpkg yet

github-actions[bot] commented 7 months ago

PR Preview Action v1.4.7 :---: :rocket: Deployed preview to https://ReadAlongs.github.io/Web-Component/pr-preview/pr-243/ on branch gh-pages at 2024-04-02 22:16 UTC

joanise commented 7 months ago

I just tested this PR, and the Web Bundle I got had

<script type="module" src='https://unpkg.com/@readalongs/web-component@^1.1.1/dist/web-component/web-component.esm.js'></script>

where I believe it will need ^1.2.0.

We have something a little tricky here: when Studio-Web and Studio-CLI start producing snippets with ^1.2.0, that will be broken until we publish that on npmjs.

Should we pause auto-updating github-pages from all pushes to main here until we publish web-component 1.2.0 to npmjs?

We're entering an unstable dev stage, that may be the safest way to go. We could change publish.yml to run on push to main_disabled in this PR and revert that change when everything is ready.

joanise commented 7 months ago

We're entering an unstable dev stage, that may be the safest way to go. We could change publish.yml to run on push to main_disabled in this PR and revert that change when everything is ready.

Or maybe a better solution is to merge to a dev branch for now, and put all breaking changes there until we're ready instead of in main.