The "deployment process" in our company (if you can even call it that) is that you usually (not always) make the site locally, then upload it to the server and after that do all changes on live server (yep...).
I am trying to push SASS in our company, but my boss basically told me that if there isn't a way for it to autocompile after a change has been made on the server, I can just throw away all my work reworking our styles to SASS and go back to pure CSS.
Here is folder structure sample of our server (we do have multiple sites running on same machine, they're all in separate sub-folders, but not all of them have frontends):
var/www/our_system/project_name1/web-frontend/frontend_name1
var/www/our_system/project_name1/web-frontend/frontend_name2
var/www/our_system/project_name2/web-frontend/frontend_name1
var/www/our_system/project_name3/web-frontend/
The frontend_nameX contains a style folder which contains folders scss and css (where I want to autocompile contents of scss into the css folder).
So, the question again:
Is there a way, to have SASS permanently watch over any sass file changes and compile them to a css folder relative to the sass folder the compiled file was in (as my boss doesn't want to run watch command for every single website)? Also, it would be amazing if it could also run the CSS through Autoprefixer.
Thanks.
Ps.: We are using our own custom CRM/CMS written in PHP, there are no other frameworks etc. Front-ends are also written in PHP and HTML (no react, node, anything of sorts). Our server runs on Debian Jessie (and for PHP we use Apache).
Ps.2: Please, do not tell me that we are doing it wrong etc. I KNOW, but I can't do anything about it.
Edit:
I got my boss to try and install Gulp on our server to take care of this, but the installation itself actually failed.
The node was installed fine, same with npm (well, I think it threw some warnings, but got installed), but gulp just threw warnings and errored out (it installed fine globally, but died when installing for the project)...
The new question is, is the gulp way to go?
All we need is something that autostarts and keeps watching all scss files and parses them when they change.
Thanks.
Related
Is it possible for me to make changes in a file of a module under node_modules directory (by SSHing to that stage unix box) and expect the UI to reflect the changes just be restarting that app on that box? Without having to rebuild?
Yes it would work but I wouldn't recommend it, it would be better to fork the module and publish your own version of it to npm with the npm publish command and use your custom module instead. If it is a bug fix, do the above but issue a pull request while trying to honor the contribution guidelines.
That is unless you are using a bundling tool that minifies and compiles the js modules to one file, in this case you would have to rebuild with the bundling tool you are using such as webpack, a grunt script etc.
I know that could be multiple answers for this question but I would know how i can fast setting up project with Bootstrap and Sass.
I had never used node, npm, grunt or bower, I've installed all already but i can't really find a good tutorial for:
Setting up the project structure
Auto compile sass files on save
(Maybe) Live reload in chrome?
I would suggest not using any boilerplate for your first project as you want to get into the "guts" of it, and once you are familiar with basics, then you can try boilerplate and see what they can do for you.
Few tools you would need to setup a project from scratch includes: Node's npm, Bower, Gulp (for example).
After you have those installed, you can dig in into creating your first project.
1) Initialize your npm project
2) Pull the packages with Bower (Bootstrap scss for starters)
2a) Pull the Specific Bootstrap 3 SCSS port
3) Configure Basic Gulp-scss config for your SCSS needs.
Basic idea behind Bower is that you have unmodified source of plugins/3rd party js/css in bower_components folder, and you use those files to compile a production ready files (js/css). What this means is that your bower_components folder is a "src" folder, and you have to add your "dist" or distributable files. Gulp helps with this part.
For the project structure, further readings and improvements on gulp tasks.
Once you have basic working project, you can try expanding your gulp-config with, like you mentioned Browser Sync and others.
I did compile a "general tasks" gulp file that i use from project to project. You can take a look here and use it if you find it fits.
Hope it helps.
You can try using Aldryn's boilerplate:
https://github.com/aldryn/aldryn-boilerplate-bootstrap3
Documentation
I understand, in general, the most frequent way Grunt is used on Heroku -- load the buildpack, specify your grunt heroku task(s), and include any Grunt plugins you want to use on the Heroku dyno in your package.json:dependencies.
However, I find this to be a rather poor solution, because it miscommunicates about my app. My Grunt plugins are all more like devDependencies, as I will only run anything with Grunt one time (per deploy). My app doesn't directly depend on them to run, as it's mostly minification and template compilation.
I'm also trying to keep compiled files (e.g. .css and .html files when I'm writing in Sass and Handlebars) out of source control, so pushing them over from Github is possible but definitely not what I want.
Is there a way to do all of the following?
exclude .css and .html files from Git
write stylesheets and markup using Sass and Handlebars
push a basic Express app containing these files to Heroku
have Heroku run a server-relative version of my grunt build task (naming it whatever is necessary is fine) to compile and prepare all of the views and assets before launching the web: process
have Heroku's Grunt task intelligently understand that I just want some pre-launch compilation so it will look at devDependencies and install the relevant ones in a perhaps-temporary kind of way
launch the Express server via the web: process
I'm fine with having to write my own buildpack, or whatever needs to be done to do this (what I perceive to be) the right way.
I created the buildpack heroku-buildpack-webapp-client that supports grunt, compass/sass and installs your devDependencies. Maybe you can use this one or have a look at the bin/compile script to see how it works.
So I have created a pretty default keystoneJS project and the first error that appeared was that when ran locally the website's default css won't load.
It's looking for site.min.css but in the folder there is only site.scss
After I compiled the scss via sublime text 2 sublimeBuild and renamed the file to site.min.css (from site.css) it ran perfectly but what worries me is why does the default installation have this error.
Where should I change this? Is there an scss builder included so I have to change folder naming or is there some other issue?
My guess is that it has something to do with some step skipped. I remember the keystone installation asked me whether I wanted to use sass so I suppose everything should be ok.
Is the problem because I did not use grunt somehow?
I recall reading somewhere that this grunt tool has to be used instead of node when running a server and I see a Gruntfile in my folder but when installed grunt-cli the grunt just loads and terminates the server right after that.
You don't have to do anything, sass-middleware is included and automatically generates CSS files from your SASS source files when they're requested.
The issue you were experiencing with site.min.css not being found was an error in the yeoman generator, from when the SASS support was added. The LESS middleware automatically compresses generated CSS when a request is made for a file ending in .min.css, but the SASS middleware doesn't do the same, so the request was 404'ing.
The problem with the yeoman generator has been fixed as of version 0.2.9, for existing projects the simple fix is to change your layout file so it refers to site.css instead of site.min.css.
Once you do that the middleware will automatically detect the presence of site.scss and generate an up-to-date version of site.css for you.
With the default version of sails on npm (v.9?) --linker works ok i.e. creates /linker folder. I can copy js, css files to assets/linker/ and they appear in layout.ejs automatically.
I now have sails v0.10 installed both locally and globally. Using Node V0.10.25.
I created a new sails project using:
sails new project_name --linker
but no /linker folder is created.
I had to create /.tmp as it did not exist
I had to create /.tmp/public/linker/ to put /js & /styles
and add them manually into layout.ejs
I renamed Gruntfile.js and my program still works thus Gruntfile does nothing in the program.
Sails v0.10 no longer uses the linker folder--it was just causing confusion. If you have the linker option enabled, then any assets under your assets folder will be copied over to your .tmp/public folder by Grunt when Sails is lifted. The public folder will be created by Grunt as necessary. The grunt-sync task will then keep the folders synced as long as the program is running.
Sails projects are not dependent on Grunt, so renaming the Gruntfile (or removing it completely) won't stop the program from working, but that doesn't mean it's not doing anything when it's there! To see what Grunt is up to, you can lift Sails with sails lift --verbose.
As an add-on to sgress454's answer, the reason a .tmp folder is created is so that files like the ejs and less files can be compiled into formats that your browser will understand. It's similar to the way that when you compile Java, it converts to Java bytecode (just an analogy, definitely not the same process).There doesn't necessarily have to be any .tmp folder when you're not running the server though; this is something Grunt creates and is what the browser reads from. Hope this clarifies things a bit more.