I was wondering how you would go about managing .SCSS files when a project has launched. For example I manage a number of websites & use the power of SCSS while building them.
However once a project has launched if I'm required to make a small edit currently I just ftp to the minified .css file and tag the extra few lines to the bottom... Bad I know!
Then when it comes to a larger change to an existing project the .scss files are rendered unless as the .css is ahead of the .scss therefore re-compiling the .scss will overwrite smaller chnages that have taken place.
The only way I could think to go about this would be to create an _updates.scss file and tagging all the small updates into this file. However this will take much longer than the current ftp'd changes.
What would you recommend?
I'd suggest still using Sass, it seems a waste not to after you've used it this far too for building the majority of the styling. It sounds like less of a Sass vs CSS issue (once on live) but more of a poor workflow.
If it seems slow editing once it's on live, consider an improved workflow - Use Git for version control (or similar), and possibly setup deployments, along with Grunt/Gulp to make Sass watches and recompiling a little easier to once it's all setup (sometimes it's a good idea to extend the functionality of these task runners to lint and minify code). Then you can stay up to date (using Git), make required changes and then you can deploy the compiled stylesheets. I use this simple workflow for a lot of projects, big and small and it's very efficient. Keeping an efficient level of maintainability for codebases is essential i think, and the first place you can improve this is your workflow. (see above)
Related
My team maintains an old coffeescript+knockout UI, of which we're slowly replacing pieces with modern React code. The project has a complicated build system, but we've been able to hook create-react-app into it and inject the bundled files into the main app. This works, but rebuilds are costly.
How can I improve our development experience by editing whatever we can inside the browser, rather than waiting for a full rebuild on each change?
In some cases we can just use the CRA dev server which is great, but we often rely on styling and code from the rest of the app so working on each component in complete isolation is difficult.
Thanks!
For CSS you can always use your browser's dev tools to change styles until it looks nice, then you copy from dev tools to your app and only have to rebuild once.
For JS you could use Hot Module Replacement (HMR) as a webpack plugin (not included in CRA, you will have to eject).
My Django project's team is looking to have the designer's CSS in a central place, preferably on the production server (so that there's one "truth" to the current design, a model he claims that he's worked with in the past). Assuming that this is even a good practice, it would mean setting up Git to deploy the CSS in a Continuous Integration (CI) manner to production.
However, I would want to restrict Git somehow for the designer so that he doesn't accidentally update any files other than CSS or HTML. Python and Django files would be updated by developers, who would be deploying in a more traditional manner: working in their own branches and only having a human build manager
merging everything in to master when tested and ready.
Part of the reason that we want the designer to be able to deploy the CSS to a server is to avoid setting up the Django site locally on his laptop (he's not so technical outside of CSS, HTML, and Git).
Is this setup even a good idea? If not, what's the proper alternative?
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
Is this setup even a good idea? If not, what's the proper alternative?
I have some reservations. It sounds like your designer is going to be the only person pushing changes to production without any gates: no code review, no tests, etc. Continuous integration is great, but a sane process includes safeties that prevent bad deploys. Since the rest of the team is following a different process, you'll end up managing two different pipelines. That's a waste of effort, and inevitably one of them (probably the designer's) falls apart due to lack of attention.
The alternative is put everyone on the same process. Teach the designer how to run the application locally, or build a harness that makes it easier. Unless your site is entirely static, how can they even see what their changes look like without that? Maybe it's more work to train them up, but it's an excellent opportunity for personal growth.
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
If you go this route, you can use Git hooks to restrict what the designer is allowed to commit. You can either put a pre-commit hook on their client or, if you control the server, a pre-receive hook that runs for only the designer's user. Either one can look at the committed files and block the commit/push if any are not CSS or HTML. There's a pre-commit framework called Overcommit that might be helpful to you. If you're using a code review tool, most have places you can hook in a bot to leave a comment or block the merge when they've modified a file they shouldn't have.
Another option here is trust your coworker. Presumably they were hired because they're effective and useful, so you can save a lot of effort building up restrictions if instead everyone's clear on what they're supposed to be doing and generally doesn't screw it up.
I have a basic question about Foundation5 setup, and associated publishing workflow. I'm on a learning curve towards creating a better local dev-to-publish workflow, so bear with me please...
Currently, I create F5 Compass projects; straightforward, but lacks programatic minification, concatenation, (CSS) cleaning, etc. LibSass projects, and a process like this, seem to readily offer these capabilities.
My question, essentially, if this is correct, and if not, how such capabilities can be added to a Compass project? I ask this simply because I have existing Compass projects under development that could use the aforementioned utilities and, also as mentioned, I want to build a better approach in general.
Conceivably, I could migrate existing Compass projects (local instances of ModX) to LibSass, but I'm sure this would come with complications.
Thanks in advance for your input.
Our team works with many websites that use Sass/Compass to compile and minify CSS.
Working with this current setup is great when you have all of the files stored locally and your development workflow is setup. However, when you push the site live and a few days down the road are asked to make a change, it's not a huge deal, the local files are there and you just have to compile and push up again.
But if you are working with a site someone else pushed live and now need to make a small change requested by the client, you have to pull all the files down, setup the development workflow with Sass/Compass and make the changes then compile and push up again.
This process is extremely time consuming when you have to make 20 small changes in a day.
It would be ideal to only have to:
pull one file down,
make the change,
push it live and somehow the server complies it.
I haven't been able to find a solution and I also am not an experienced server side developer, so I'm asking you guys if you have a better development workflow setup that allows for all of this to happen and yet, makes it easy to make small changes in the future.
Little information, but I think it would have to do to use partial file css several are not generated to compile.
I am getting into less.js, for development and production on client sites. It's amazing how it can extend CSS, and for me there isn't really that much difference in speed when using it.
I'm wondering if it's really that important to keep a .css fallback file for less.js? I'm sure if a user is browsing without JavaScript enabled, then they wouldn't really be able to browse much other sites anyways. What do you think? Does it really matter?
Some say it's not mean't for production, but is that true?
If your using less I suggest you precompile your less files into CSS files. Relying on less to parse your css files on the client side is introducing another point of failure.
On their website http://lesscss.org/ there are plenty of examples of how to do this.
If your using .NET you can use T4 Templates or you can use DotLess which uses an httphandler to compile the less file on the fly server side.