[GitHub] [airflow] mik-laj commented on pull request #13313: Warns politely, do not force run a long operation

[GitBox <gi...@apache.org>]

mik-laj commented on pull request #13313:
URL: https://github.com/apache/airflow/pull/13313#issuecomment-752955409


   > I think we should stil recompile automatically when user runs 'start-airflow' command. In such case there is no chance to recompile the assets manually.
   
   I've added a new panel that compiles all files that have changed and then monitors for any new changes.
   
   > I think this is much better approach than warning.
   
   ```
   time yarn run build
   real	0m22.657s
   ```
   On my computer, it still takes 20 seconds. In my opinion, this time is wasted, especially when I frequently change branches and these files will recompile when I switch branches.  I suspect most developers will feel similar as we don't have too many JS developers.  When there are more JS developers, we can try to improve their workflow, but for now I would rather make life easier for a larger group.
   
   > We should decide if we should use build or prod and use the same in both cases (AFAIK prod is optimized version of assets) (@ryanahamilton WDYT ?). I'd vote for build as it produces un-obfuscated code if that's the case..
   
   I also think it is worth having access to non-optimized files.
   
   > We should calculate and store the md5sum also in case of Dockerfile.ci build (because otherwise it will be always rebuilt first time).
   
   I used the `airflow/www/compile_assets.sh` script in Dockerfile, so now the checksums are also generated.
   
   > One more thought @mik-laj . Maybe we should also split node_modules vs. compiling assets? Right now we are doing both which is probably not the best idea and this is main reason why it takes so long on Mac mounted filesystem is slow and it scans many files while doing yarn install - that's why for me on Linux it takes seconds and for anyone working on Mac it might take minutes (that's why I have no noticed that this is a problem).
   
   In my opinion, this has very big benefits. This way, one script prepares all JS files and solves any Javascript issues. I don't have to worry if I should use `yarn install` or` yarn run build` in a given situation. In our community, where most developers don't use these tools every day, this has a huge benefit. I just run this script and it doesn't care anymore.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org