monicahq / monica

Personal CRM. Remember everything about your friends, family and business relationships.
https://beta.monicahq.com
GNU Affero General Public License v3.0
21.64k stars 2.16k forks source link

Remove any pre-compiled assets from the codebase #136

Closed Kovah closed 3 years ago

Kovah commented 7 years ago

Currently, there are four different CSS files in the /public/build/css directory and two js files.

I would recommend to build the project with all needed components and upload a zip file to the releases section.

Example script

# Install all the needed stuff
composer install
npm install
bower install

# Prepare config files
cp .env.example .env
php artisan storage:link

# Compile the assets
gulp --production

# Create a database, do all migrations
# @TODO Export the database to a dump file that can be imported into the users database
php artisan migrate

Then zip it, upload it and add a note to the readme that the user has to add his own database credentials in the .env file. That's it.

Another example is this build script I use for InvoicePlane: https://gist.github.com/Kovah/3bde87799457cbb139b0eba48c871549

This is related to #30 - Implement a setup.

erdmenchen commented 7 years ago

This would also help for updating. see #96 One more result of this approach would be to (finally) have a version and release scheme.

djaiss commented 7 years ago

@Kovah didn't know InvoicePlane, thanks so much for sharing it.

Removing pre-compiled assets is something that I'd like to do. I'm just not sure how I would do it. Any indications? That means I'd need to build the files on the server on each git pull.

Kovah commented 7 years ago

Yes, people would have to rebuild their assets after each pull if they directly use the git repository. But it's just one command that can be chained into one update command like git pull && php artisan migrate && gulp --production

The only thing you would have to do is to build a package that can be downloaded, for users that are not familiar with git and so on. As you already use versioning you would have to run the updating for the package only once after releasing a version and upload the package to the release here on Github.

tcmal commented 6 years ago

Should the production Dockerfile depend on the current folder already being fully built? Or should it build it as part of the image process? It already installs composer dependencies so I think either way it should be more consistent than it is now.

github-actions[bot] commented 3 years ago

:tada: This issue has been resolved in version 2.22.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] commented 3 years ago

:tada: This issue has been resolved in version 3.0.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.