Storing aggregated CSS and JS on S3 - is this possible now?

This appears to be mostly a duplicate of ✨ Add support for s3fs to use the assets:// stream wrapper Postponed with most of the questions asked already answered in that issue and ongoing discussion about deployment and impacts.

The only question I can see that is not directly answered is regarding the path, which I will note Drupal core allows changing, it must be below the web root however it does not need to be in sites/files.

Closing as a duplicate to keep the issues consolidated.

This is not a duplicate.

The other task muddies the issue considerably for those of us who are not well versed in "stateless infrastructure" or Kubernetes and then talks about setting up persistent volumes with shared EFS for each Pod.

The other thread is about how to handle the core change within S3FS. This one is about explicitly and as simply as possible explaining to users of the module who may not be as well versed in all this as yourself what the situation is.

We need a clear statement of what this change means (maybe on the module page) for S3 because for me at least the module used to work fine without going through too many hoops and now it doesn't because of the core change.

I am no closer now to knowing if there is a way I can get it to work or if I am wasting my time.

This one is about explicitly and as simply as possible explaining to users of the module who may not be as well versed in all this as yourself what the situation is.

To try and put it more clearly.

Change Description:
Prior to 10.1 Drupal generated CSS/JS files when a page is loaded (such as http://example.org/node/123).
Prior to 10.1 Drupal stored CSS/JS files in the public:// streamWrapper. These files must exist when the browser requests them or the page will not render correctly.

As of Drupal 10.1 Drupal Core now stores CSS/JS in the assets:// streamWrapper.
As of Drupal 10.1 these files are generated "on demand" when a user(browser) requests them.

What the means:
Persistent shared storage (s3fs) is no longer required for CSS/JS files.

The URL to retrieve these files contains all the information needed to create the file if it does not exist. Writable storage must exist on each server that will generate CSS/JS files to store these files. The storage does not need to be shared between servers. Drupal Core allows configuring where these files will be stored.

As of right now it is not possible to store CSS/JS assets in D10.1+ in s3fs. ✨ Add support for s3fs to use the assets:// stream wrapper Postponed is the feature request thread to discuss adding support for assets:// storage however it is awaiting justification that such a feature is actually needed given the significant technical costs and degradation in performance gains the feature would add.

Documentation:
Our ability to effectively document this is limited, as a project we only control the docs for s3fs while most of this should be in Drupal Core Documentation.

The s3fs README.txt and release notes were previously updated to include a note that this behavior change occurred.

I think that's much clearer. Many thanks.

I've only tested on one site so far but the s3fs_assets → module seems to resolve the issue so far and allows us to have the aggregated css and JS files on S3 again.

Thanks

I was unaware of s3fs_assets.

Sounds like this issue can be marked as fixed as none of that is related to answering the question of does s3fs support assets://.

Automatically closed - issue fixed for 2 weeks with no activity.