Committing production files

Hello everyone!

I’m committing my theme using git-ftp, and also wasn’t able to run any CLI commands from the web server.

I only have the node_modules under my .gitignore

Since I’m committing a production build, is it okay also to ignore SASS files since webpack generates a minified hashed css file?

As a webpack and Sage newbie, by default, the “dist” folder is also in .gitignore, I wonder how Sage9 would have the assets without the “dist” folder? So for now, I have the “dist” folder committed which seems wrong.

Thanks in advance!

Have a nice day and stay safe guys.

Regards,
Kristian

Are you asking if it’s okay to not commit the files that are the authoritative source for your CSS? I would strongly recommend against it. If you don’t commit your scss files, then your repo will have no record of them, and anyone (including you) pulling down that repo in the future would then be unable to build your site.

The dist folder is ignored because the intent of Sage is that you do not commit built assets to your repo. The ideal deployment strategy is Trellis, or something similar, that builds and pushes your assets as part of the deploy. In a sense, your Sage repo is not meant to be the theme: It is meant to be a set of source files and instructions for the build process to create the theme at build time.

If you want a better understanding of Sage, and the rest of the Roots stack, I’d recommend reading our series on 12-Factor App methodology w/r/t WordPress: Twelve-Factor WordPress App | Roots

1 Like

Hi alwaysblank,

Thank you for making a time for replying to a very newbie question.

And now, you just gave me an idea how much I’ve been doing things wrong. I’ve been using my Sage repo as a theme, because that’s the only way I know how, and since however, still works.

I would invest a lot of time reading into Trellis.

Thank you so much, alwaysblank!

There are two strategies:

  1. “dirty” commits: The build artifacts are committed into the repository.
  2. Transfer the artifacts separately.

Well, there is also a third way, which would could be overengineered though:
The theme is build as a package, including the source and the build artificats (dist), pushed onto a (private) composer repository and then pulled/installed from the site on production system.
One step further one could bake the whole site with theme into an immutable docker image (with database connected and uploads/ directory mounted into).

Hi,

I think I’m with the “dirty” commits. Also, the idea of having the resources such as styles and scripts under .gitignore is to make them unavailable/inaccessible for others. Since I am developing the theme in solo, and the files are in my local. Also, I’m only using git ftp to commit and push files.

The only thing that changed my mind was the “future” phase. I won’t be having the back-up of ignored files stored online.

Regards

IMO this approach is shortsighted and counter to the purpose of git as software and version control as a concept. I strongly urge you to reconsider. Commit your build artifacts to your repo if you must, but please don’t ignore your source files. Future you will regret it. If you really don’t want people to have access to your SCSS files, you can use server directives (i.e. htaccess or nginx configuation) to prevent access to those directories.

3 Likes

Thanks a lot! Have a nice day!