docs: update static assets ADR with the new plan

[kdmccormick]

We update the static assets plan based on three major things we've learned:

1. You can stick any old script under npm run via package.json, and apparently that's the standard thing to do in frontend packages. So, forget scripts/build-assets.sh, let's do npm run build!
2. Removing the special XModule asset processing was necessary in order to achieve most of the optimization goals of this ADR, so we went ahead and did it. We can remove the xmodule_assets step entirely now.
3. Upgrading from libsass-python to node-sass/dart-sass is hard any nobody has time to do it right now. Even sidegrading to a another old non-Python version of libsass proved to be difficult when I tried. So, we are stuck with libsass-python for now, which means we are stuck with writing the compile-sass script in Python. This is fine, as we can still get most of the benefits we need as long as we segment out the requirements for compile-sass from the rest of edx-platform.

Links:

• Original ADR PR: docs: add ADR: "Reimplement edx-platform static asset processing" #31790
• Rendered old ADR: https://github.com/openedx/edx-platform/blob/a6f04d8ca36949c7ccfc60d87988bf8059282df1/docs/decisions/0017-reimplement-asset-processing.rst
• Rendered new ADR: https://github.com/kdmccormick/edx-platform/blob/kdmccormick/new-assets-adr/docs/decisions/0017-reimplement-asset-processing.rst

[kdmccormick]

Extra notes for reviewers.

[kdmccormick]

Timestamping this since the line between XModule and XBlock has blurred since writing. Still, the table makes sense from the perspective of this ADR.

[kdmccormick]

As I moved towards npm run, I moved away from the structure of openedx-assets.

[kdmccormick]

This note seemed irrelevant now that npm run watch is an entirely separate command.

[kdmccormick]

This whole OPENEDX_BUILDS_ASSETS_OPTS idea doesn't play well with the simpler npm run command structure, so I removed it in favor of simple environment variables (below).

[kdmccormick]

We aren't entirely removing Python any more, so I removed this section, but I folded its arguments into the rejection of "Improve existing system" since they are largely the same.

[feanil]

One non-blocking comment but generally looks like a good improvement which leads us closer to npm and node for front-end things and python/django for backend/historic things.

I like that we don't have to have people know about a new interface for invoking commands.

[feanil]

Love this, though I know it may feel a bit duplicative to have this info in both an environment variable and in the LMS settings. In the future we could allow the user to override the setting based on a value in the environment as well so I'm not too worried about it for now.

There is an implied "We expect Django and Node to put assets in the same place for things to render properly." Is this written down somewhere or should we document it?

(Non-blocking thought.)

[kdmccormick]

Agreed all around. The specifics of things like the exact env var semantics are still in flux (hence this PR :) so I'm hoping that this ADR will tide over anyone who wants to experiment with the new assets system. Once I'm closer to removing Paver, though, I'll make sure that these sort of settings are either de-duped or documented.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.