Improve assets precompilation

[olivierobert]

Why

The template has a workaround to precompile assets for the production env. Since Rails seems to require all env variable to be set, the following add a dummy value:

rails-templates/bin/docker-assets-precompile

Lines 15 to 20 in 0e40c04

	if rails_env == 'production'
	env_keys = YAML.load_file('config/application.yml')['docker_build'].keys
	env_keys.each { |name| ENV[name] = 'dummy_value' }
	end
	exit system('bin/rails i18n:js:export && bin/rails assets:precompile')

However, with the new build process with esbuild, it seems that just setting the env variable ASSET_ENV=production is sufficient as per this article. So it might be time to revisit.

Also, it would be good to sync assets files to S3 as well instead of serving assets from Heroku.

Who Benefits?

Web developers who work on Ruby on Rails projects

[malparty]

@hoangmirs @andyduong1920 anyone willing to work on this one? :D
If this one was implemented, we would not have spent time debugging the missing adapter issue (from #191 #264 )

Thanks!! 🙇

[andyduong1920]

Hi @malparty, I'm not sure this is related to the #264 issue :D

I didn't catch up with the Rails assets tooling for a while; before starting this improvement, are we using esbuild as the default tool for modification?

Also, will we target to sync the compiled assets to S3 on the same issue 🤔 should we separate that into two different topics 🤔

[malparty]

@andyduong1920
These are 2 different issues indeed— they can be done independently I think 🤔 (starting with the assets pipeline improvement first, then configuring S3 later)

[andyduong1920]

Also @malparty FYI we might improve the asset pipeline but for the rake task like bin/rails i18n:js:export it's still required all ENV 😂 because that is the Rails way FYI

[malparty]

Yep, maybe we should use the NPM i18n package for running the export command... It might be more performance as well 😇 but this is at risk to duplicate the configuration for exporting.