Force rebuild JS bundle

[Andrew Scholer]

I keep tripping myself up while switching between different dev branches that touch the JS by forgetting to manually rebuild the JS after a context switch.

It is also a little annoying to have to manage two build chains while working on JS/CSS/HTML.

Would it make sense to have a development mode that always attempts to rebuild the JS and uses the dist copy only if npm is not available (somewhat like the CSS)?

Or, maybe that could be the default when using the pretext script? The CLI would use the prebuilt copy while the script would always attempt a rebuild. Can we already easily detect in pretext.py whether it is being run by hand via the pretext script or used as a library via the CLI? If not, it seems like that would be easy to add.

Andrew

[Rob Beezer]

Doing my best Andrew imitation, "I think so....?"

The dist/ files are minified, no? So the value of follow-on commits is
less-interesting. But I still like that it is the committer's job to do the
build. I don't want to chase merge conflicts or do surgery to get PRs merged.

And I guess I don't want the pretext/pretext behavior to visibly change for
authors/publishers/developers.

I have only screwed-up once with regard to this, and it was right at the start.
But maybe my dealings are different than yours. Other than that, maybe these
changes are not impactful on my end.

Not sure if there is a detection mechanism, but I suspect a small amount of
Python could provide it?

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_GzmyTU1zagt217bF3gbYu18wQZnEK%2BPbA46xH0emiBQ%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CACm44N_GzmyTU1zagt217bF3gbYu18wQZnEK%2BPbA46xH0emiBQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Jason Siefken]

The js/dist files do not appear to be minified.

If these files are generated by a build script, then in an idea world, these files live in a different repository and are rebuilt automatically on every merged PR (easy to do with github actions). Then the entire dist/ directory gets put under .gitignore

[Andrew Scholer]

I am more focused on the process while actually working on code, not on the final commit that gets merged.

For that part, the pretext/pretext behavior changed for developers with the addition of the JS build. It used to be that any change to JS source was seen in the book on a rebuild. Now you have to rebuild the JS, then rebuild your book. (Or rebuild JS directly to your book, or automate one/both parts.)

What I am suggesting would not change anything for authors/publishers. If they don't have node, nothing happens. If they do have node, the JS is built fresh, but that takes a fraction of a second and should match what is already in dist. If you have changed the JS, then a rebuild of the book automatically would generate new JS. That would match the CSS behavior (only drop down to prebuilt if there is no node and theme is vanilla).

I would be almost as satisfied with a flag on pretext/pretext that forces a JS rebuild. But that would be different than the CSS build behavior and it would be nice to keep them aligned.

But as for the final commit, I think that needs to be done by the reviewer (assuming it is not automated per Jason's suggestion). Even non-minified, dealing with any merge conflicts in the build product seems like an error prone waste of time. The PR generator's commit will likely be out of date by the time it is merged.

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/0b386251-3f60-4ac0-b28a-d7b1efeb559e%40gmail.com.

[Oscar Levin]

Not against adding a flag for development that rebuilds the js.  Or... I'm actually surprised we don't have a "watch/dev" mode for the javascript build.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N9pJ5a_G4ufzF6a_e4CifR%3DByFXS0J_-U2Y4z%3DmtUQU8A%40mail.gmail.com.

[Rob Beezer]

(Originally sent several hours ago.)

On 6/22/26 12:43, Andrew Scholer wrote:
> What I am suggesting would not change anything for authors/publishers. If they
> don't have node, nothing happens. If they do have node, the JS is built fresh,
> but that takes a fraction of a second and should match what is already in dist.
> If you have changed the JS, then a rebuild of the book automatically would
> generate new JS. That would match the CSS behavior (only drop down to prebuilt
> if there is no node and theme is vanilla).

Sounds good to me, since we pretty much have this sort of dependency already.
The CSS approach seems to be working well.

Do we need to hear from Oscar?

Rob