Do we need to include the SASS file in production? Can't we just deploy the compiled CSS output? How do you guys deploy your CSS/SCSS code in production?
If any of you don't include SCSS in production how do you deal with version control like Git. I assume the master version should have the SCSS file there, but pulling from production environment it should be excluded? Is this problematic?
I just want to see what the most efficient way to do this.
The reason I asked this is because, using Chrome DevTools lately I've been seeing scss files as source. To see what I mean, if you go to getbootstrap.com and inspect its styles, you'll see scss as the source.
The browser does not render or understand SASS code. Thus serving such files for the sake of styling not only is not required but it doesn't even work¹.
¹ Well, yeah, it can work—there're many SASS implementation, including a JavaScript one that can be used in a browser.
The SASS code you see in your browser's developer tools (not just Chrome) is a developer tool. In order to diagnose CSS issues you can instruct your SASS compiler to generate source maps. A source map is a document that links positions in your possibly minified CSS files to the SASS source code it comes from. When you open your developer tools and the CSS file declares a source map (example):
/*!
* Bootstrap v4.1.3 (https://getbootstrap.com/)
* Copyright 2011-2018 The Bootstrap Authors
* Copyright 2011-2018 Twitter, Inc.
* Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
*/:root{--blue:#007bff;--indigo:#6610f2;--purple:#6f[…]
/*# sourceMappingURL=bootstrap.min.css.map */
… the browser downloads the map (example) which in turn links the corresponding SASS source code files.
{"version":3,"sources":["../../scss/bootstrap.scss","../../scss/_root.scss","../../scss/_reboot.scss"[…]
Together with the file/line/column mapping information, developer tools can reconstruct the SASS code where a given element styles come from.
"mappings":"AAAA;;;;;ACAA,MAGI,OAAA,QAAA,SAAA,QAAA,SAAA,QAAA,[…]
The source files are obviously not required. Whether to include them or not depends on factors like:
Is it okay to distribute them or they contain stuff that's meant to remain private like internal comments or intellectual property?
Do you need to diagnose stuff in the live site?
Sass is converted to CSS, So you don't need to install it on the server. It only needs to be installed locally, Browser only understands CSS, SAAS is a preprocessor scripting language make your code easy to organize and edit with a little effort.
It depends on your build process. If you push Sass files and compile on the webserver when you run your deployments then yes. But I have a file structure something like this:
- src
--- styles
------ Sass files
--- js
--- images
- build
--- assets
------ styles
--------- CSS files
------ js
------ images
So I push everything into git and before I deploy changes to live I run my build commands* locally then push everything into Git.
From here, I deploy everything within the /build directory up onto the webserver for my site.
* My build commands are my regular compiling commands except I minify on build only.
Related
Though I hate it, I chugged down most of the theory of modern web design.
Let's pretend I am doing a full stack website with no heavy machinery in the background (node, server side stuff etc) just old plain html/css/js.
Now I did a npm init in the folder where I'm developing the website.
I put in bootstrap along with jquery, popper and all its dependencies.
Now I want to include bootstrap in the page.
How?
Though I never saw browserify and webpack before, I've read they are useful for js only so you can "require('module')" in your javascript code but no use for css in the frontend (html files).
For those, I saw people suggesting to point to a folder and prepare grunt (javascript task runner) scripts to copy css in folders where you point at.
There is any way?
My conclusion is:
NPM/browserify/webpack = Useless rube goldberg machine until you start developing javascript/node in the background
Solution: Old CDN/Download local copy and link it in the code
What am I missing?
As I continue to make progress on my app my stylesheets folder has quickly become overrun. I've read the rails guide on the asset pipeline, and scoured the internet for a reputable source and am still at a loss on the "rails way" to keep everything tidy.
Before I go and try and develop a system by myself I was hoping to get some suggestions from you guys.
Is there a well known "best practice" when it comes to asset organization? If not, what has worked well for you?
As of now my setup is this:
app/assets/stylesheets >
application.css, application-RESPONSIVE.css
any code specific to the body, containers, navbar, footer
controller.scss, controller-RESPONSIVE
*any code specific to that controller
lib/assets/stylesheets >
reset.css
in application.css i use
*= require reset
*= require_tree .
*= require_self
To get all the styles however I've also been wondering if its better to set self before tree as a means of overriding the main styles if need be?
Is there a well known "best practice" when it comes to asset organization?
Organization of assets:
In Rails, pipeline assets can be placed inside an application in one of three locations: app/assets, lib/assets or vendor/assets.
1) app/assets is for assets that are owned by the application, such as custom images, JavaScript files or stylesheets.
2) lib/assets is for your own libraries' code that doesn't really fit into the scope of the application or those libraries which are shared across applications.
3) vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins and CSS frameworks.
Is it better to set self before tree as a means of overriding the main styles if need be?
application.css is what is called a manifest file. Now, it wouldn't particularly make any difference by switching self with tree, but it would change it's position in the loading sequence. Consider this...
Once you’ve placed your assets in their logical locations, you can use manifest files to tell Rails (via the Sprockets gem) how to combine them to form single files. These manifest files contain directives - instructions that tell Sprockets which files to require in order to build a single CSS or JavaScript file.
Additional info:
One other thing that Rails does, is generate stylesheets for you when you run the rails generate command in the terminal. On creation of a new controller, you'll see a stylesheet with the controller's name in your assets. It'll look something like app/assets/stylesheets/newcontroller.css.scss
Also, what steve klein said.
Hope this helps you out.
UPDATE:
I've tried looking for examples on github but all of the apps I have found have been too simple and havent shown any advanced organization for a large amount of files.
I encourage you to check out Open Source Rails website. I have looked at some projects there and they seem complex enough for you to be interested enough. Especially, look at the Discourse app. Discourse was co-founded by Jeff Atwood, co-founder of Stack Overflow. That I suppose speaks for itself ;)
I'm running JetBrains ReSharper 8.2 on a project that uses SASS for styling.
I compile my seperate scss files into one file "common.css". This file is not included in the project, but gets compiled on build on the server (grunt + compass takes care of this).
I don't want to include this file, but only my SCSS files in the project. This however causes ReSharper to report a lot of errors ("Unknown CSS class"...) in my views because the file isn't included.
Is there a workaround for this (without disabling css errors in settings)?
I've tried the "ReSharper.ExternalCode" extension (https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode), but without any luck.
Sadly, there isn't a workaround for this. ReSharper doesn't know about SCSS files, and doesn't know anything about files that aren't included in the project, so it can only assume the CSS classes are undefined.
The external code plugin should work and allow ReSharper to process the resulting css file. However, I'm not sure how flexible it is - I think it needs everything to be configured before the solution is opened. That is, it only tells ReSharper about the generated file when the solution is being opened. Configuring things while a solution is open probably won't be reflected immediately (but I haven't tried it). Similarly, it doesn't notify ReSharper of changes to the file, and I don't think that ReSharper sets up any monitoring. So if the file isn't available when the solution opens, or changes while it's open, ReSharper won't have correct information. I'd try and configure it, close the solution and reopen.
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
I'm using SquishIt and have a .less file which I add to a CSS bundle with the following line
.Add("~/content/styles/dev.less")
This compiles as dev.less.debug.css when I build the solution, however I'd like to be able to just save the .less file and it automatically compiles the css (so I see the change instantly in my browser as I would with a traditional CSS file).
I have looked at a number of extensions to achieve this (such as LessExtension and LessCssForVisualStudio) but these require the file to be added to the bundle as dev.css rather than dev.less. Mindscape Web Workbench does not compile LESS files in its free version so I do not know if it also requires dev.css.
I can't change the link to the file as the project will be worked on across teams, where some won't install an extension and will be happy to build the solution to compile.
Is there and extension that automatically compiles LESS that is built to work with SquishIt?
If you use it on non-production site, I would suggest using less.js (It will render css with js on client-side).
Squishit uses dotless under the hood, so you could use that directly.. either set it up so that you request the less file and a handler returns CSS or you can use the exe to compile on build and also the watch mode... I'm not sure what's best for you, but you can find more information on the dotless wiki (https://github.com/dotless/dotless/wiki/Using-.less)
Web essentials does this job perfectly and its free.
http://vswebessentials.com/