build: compile/watch sass with new npm scripts#34318
build: compile/watch sass with new npm scripts#34318kdmccormick merged 3 commits intoopenedx:masterfrom
Conversation
774415c to
f233e8d
Compare
npm compile-sass, with temporary paver compat wrapper
npm compile-sass, with temporary paver compat wrapperpaver compile_sass wrap npm run compile-sass
c9048ea to
936b18a
Compare
|
Sandbox deployment failed 💥 |
|
Sandbox deployment failed 💥 |
|
Sandbox deployment successful 🚀 |
936b18a to
2b3d56b
Compare
|
Sandbox deployment successful 🚀 |
|
Sandbox deployment successful 🚀 |
2b3d56b to
c174d83
Compare
|
Sandbox deployment successful 🚀 |
c174d83 to
42fe781
Compare
paver compile_sass wrap npm run compile-sassnpm run compile-sass
npm run compile-sass|
Sandbox deployment successful 🚀 |
42fe781 to
b6a6ffb
Compare
|
Sandbox deployment successful 🚀 |
b6a6ffb to
0c200ea
Compare
|
Sandbox deployment successful 🚀 |
0c200ea to
9d027dc
Compare
|
Sandbox deployment successful 🚀 |
9d027dc to
a643b8c
Compare
|
Sandbox deployment successful 🚀 |
a643b8c to
49a2f38
Compare
|
@feanil friendly reminder about this PR. The follow-up PR is also ready for review, if you want to review them in one swoop: |
|
Sandbox deployment successful 🚀 |
feanil
left a comment
There was a problem hiding this comment.
Looks good, I was able to run the assets commands and see things working locally.
The implementation of `npm run watch-sass` was trying really hard to recompile precisely only the Sass that needed to be recompiled, but in order to do so, it had to spin up several `watchmedo` processes per theme. These processes would trigger one another sometimes, leading to infinite recompilation loops. Rather than figure out all the dependency directions and messing with `watchmedo`, I've opted to simplify the script to invoke a single `watchmedo` process per theme. A single theme recompiles within seconds, so I think this is a good compromise, one which makes the script easier to reason about will help me move pass this legacy assets work.
`paver` commands are deprecated for managing static assets. Starting in Sumac, only `npm run` commands will be supported for managing static assets. To ease the transition, both `paver` and `npm run` commands will work in Redwood. However, we want to stop using the *implementations* of the `paver` asset commands right now, as they are blocking the Python 3.11 upgrade. This will also make the removal of `paver` commands more straightforward come Sumac. So, this commit turns these commands/functions: * paver compile_sass (used by configuration) * paver watch_sass (used by configuration and devstack) * pavelib/assets.py:_compile_sass (used by Tutor) into very thin wrappers around the new `npm run` commands. Each of these paver routines now raise a loud deprecation warning, including a message of the `npm run` command that the operator can switch to. We expect no impact to site operators or end users. openedx#31895
49a2f38 to
a228b81
Compare
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
|
2U Release Notice: This PR has been deployed to the edX production environment. |
1 similar comment
|
2U Release Notice: This PR has been deployed to the edX production environment. |
Description
pavercommands are deprecated for managing static assets. Starting in Sumac, onlynpm runcommands will be supported for managing static assets.To ease the transition, both
paverandnpm runcommands will work in Redwood. However, we want to stop using the implementations of thepaverasset commands right now, as they are blocking the Python 3.11 upgrade. This will also make the removal ofpavercommands more straightforward come Sumac.So, this commit turns these commands/functions:
into very thin wrappers around the new
npm runcommands. Each of these paver routines now raise a loud deprecation warning, including a message of thenpm runcommand that the operator can switch to.We expect no impact to site operators or end users.
Also included in separate commits
Supporting Information
Testing
With Tutor
tutor plugins install indigotutor mounts add <path to your edx-platform>tutor dev stop && tutor local stoptutor config savetutor images build openedx openedx-devtutor local start -dtutor local do settheme indigotutor local do settheme defaulttutor dev start -dtutor dev do settheme indigotutor dev run lms env EDX_PLATFORM_THEME_DIRS=/openedx/themes npm run watch-sasstouch "$(tutor config printroot)/env/build/openedx/themes/indigo/lms/static/sass/_background.scss"tutor dev run watchthemesseems to lead to an infinite recompilation loop any time any themed Sass file is changed. I have authored this PR to be technically compatible withtutor dev run watchthemes, but I'm not worried about fixing the infinite recompilation bug here.Without Tutor
To test outside of Tutor, I recommend just building static assets however you normally would. For example, I believe
paver update_assetswill do the trick for folks using devstack and configuration.Merge Considerations
I am aiming for this week (Thu March 28 if possible) in order to unblock the Python upgrade, which needs to be complete for the Redwood cut in late April.
Priorities after merging this:
sassmodule #34439 (This will unblock the Python 3.11 upgrade)./manage.py compile_sass, which is used for site theme compilation, to usenpm rundirectly instead of going throughpaver