Research
Security News
Kill Switch Hidden in npm Packages Typosquatting Chalk and Chokidar
Socket researchers found several malicious npm packages typosquatting Chalk and Chokidar, targeting Node.js developers with kill switches and data theft.
scally-test
Advanced tools
Version 2 is coming in the next few days, in the meantime take a look at the v2 branch and it's CHANGELOG.md.
Scally is a Sass-based, BEM, OOCSS, responsive ready, CSS framework that provides you with a solid foundation for building reusable UI's quickly. It is a framework focused on scalability and reuse, there when you need it and getting out of your way when you don't.
Scally is designed to be configurable, only requiring you to bring in the parts you are using, keeping your CSS architecture light weight and scalable. It is unopinionated about design giving you more flexibility than your typical UI toolkit.
A website—featuring demos of everything in Scally—is coming soon, in the meantime they're CodePen's that can be looked at but are a work in progress:
Scally is broken down into five main sections with each section getting it's own level of specificity meaning each one builds on top of the other in terms of inheritance and CSS' first C; the cascade. Think of them as layers:
The breakdown of these layers from bottom to top (order of their specificity):
Ruby, if you're using a Mac then Ruby comes pre-installed
Autoprefixer parses CSS and adds vendor-prefixed CSS properties using the Can I Use database.
We advise you to setup Autoprefixer as part of your build process e.g. if you're using Grunt then you can create a Grunt task for Autoprefixer using something like
Scally can be installed as a package with either:
You'll need Node.js installed to use the npm and Bower packages, more information on installing npm here. Once npm is installed you're good to install the Scally npm package by cd
ing into your project folder (the root is recommended) and running this command:
npm install scally
For the Scally Bower package you first need to install Bower via npm like so:
npm install -g bower
Then, just like the npm package, you cd
into your project folder (the root is recommended) and run this command:
bower install scally
Once the package is installed your project will look like this:
npm
project root
│
└───node_modules
│
└───scally
Bower
project root
│
└───bower_components
│
└───scally
Once installed you can always get the latest version of Scally by running the following commands:
npm update scally
bower update scally
N.B. Scally should never be edited or added too directly. If you ever make changes directly in Scally you will not be able to seamlessly update your version of Scally to the latest version.
This is a very simple overview of npm and Bower so if you're new to them then please take the time to read up on them.
You can install Scally via the Download by zip option however it's advised to use a package manager like npm or Bower to handle your third-party dependencies.
Once you have installed Scally you will need to create a master Sass stylesheet called style.scss
, that will live in the root of the folder where you keep all of your CSS.
Once you have created this file grab everything from here and paste it into your master stylesheet then read the next section: Master stylesheet overview.
This master stylesheet is what you will link too from your HTML head, once compiled that is, you can run a basic Sass watch command to compile your Sass, like this:
sass --watch style.scss:style.css
But for most projects your Sass will be compiling as part of your build process e.g. if you're using Grunt then you can create a Grunt task to compile Sass using something like.
Then add a reference to the compiled master stylesheet in your HTML head:
<link href="[path/to/your/css/folder]/style.css" rel="stylesheet">
This master stylesheet is designed to pull in everything from Scally–however only the Core section is mandatory–plus your project-specific styles and compile down to a single css file.
Your master stylesheet is split into three main sections:
N.B. it's imperative this order is maintained otherwise Scally won't work.
This first section consists of one Sass partial:
@import "settings";
Which should live at the same level in your project file structure as your master stylesheet: style.scss
, see an example here.
In this partial you will store all of your common project-specific settings, beyond what Scally offers. Typically you won't have many of these.
Common project-specific settings might be adding more colours, so if you decide you need a new colour then in settings.scss
you can create one like so:
$color-tertiary: #ccc;
Another example might be adding a new font family e.g.
$font-family-droid-sans: "Droid Sans", serif;
The reason this section comes first is so that you can refer to them throughout the rest of your styles.
This section pulls in the entire Scally framework and is where you override Scally's settings.
This is what makes Scally so powerful, as Scally can be completely modified by changing the settings without ever having to alter the framework itself.
So for example if you wanted to change the global font size for your project then you assign a new value to the relevant Scally setting which in this case would be $font-size
then simply declare it above the relevant @import
partial in style.scss
, like so:
$font-size: 14;
@import "bower_components/scally/core/settings/typography";
You can use your own project-specific settings from your settings.scss
file to override any of the Scally settings e.g.
$color-text-base: $color-hotpink;
@import "bower_components/scally/core/settings/colours";
By default everything in the framework is imported. But if you want to be selective and you definitely should, so your CSS is as lean as possible, then only import what you need.
So if you decide you only need to use half of Scally's utilities then simply remove the relevant utility partial @import
s you don't need from style.scss
.
However the Core section is required, please do not remove any of the imports from this section.
This section is where you pull in all of your project-specific styles. We recommend following the same architecture as the Scally framework.
So you may end up with your project setup like this, assuming that you contain all of your CSS in a folder called css
and you use Bower as your package manager.
project root
│
└───bower_components
| |
| └───scally
|
└───css
| style.scss
| settings.scss
|
└───partials
|
├───components
To ensure a consistently authored code base and to keep things clean and readable Scally uses the scss-lint tool.
To install run the following command:
gem install scss-lint
To use cd
into your project's root and run the command:
scss-lint ./
Which will lint everything, to lint at a more granular level see.
Scally's linting rules can be found here and are based off these CSS authoring guidelines.
Scally gratefully welcomes contributions from the open-source community but there are a number of requirements and principles that need to be adhered for code to eligible for inclusion in the framework.
Scally is written in Sass, which provides a lot of incredibly powerful features. However, Scally does not want to become a platform for Sass' capabilities—all code that comes into Scally should be as simple and CSS-like as possible.
Adding this complexity is against a number of Scally's core principles especially in team-based workflows, long-running and larger projects, and its flexibility.
Kinds of code not good for Scally:
In addition to the principles outlined above here are some things to keep in mind when submitting code to Scally via a PR (Pull Request):
Credit: alot of this section was taken from and inspired by the Contributing section of inuit.css.
If you would like to suggest any new additions to Scally, any improvements, log any issues or bugs, or just ask a question, please open a new issue and label appropriately.
Scally is maintained under the Semantic Versioning guidelines however sometimes we get it wrong, but we will do our best to adhere to those rules as much as possible and strive to maintain backwards compatibility.
Copyright 2014 Westfield Labs Corporation.
Copyright 2015 Chris Pearce.
Licensed under the Apache v2.0 license.
Scally was originally created at Westfield Labs whilst I was an employee there.
Scally was something I brought to Westfield Labs, and something I worked on full-time for a period of time as the main developer. Other Westfield Labs employees who contributed to Scally at that time:
After I finished at Westfield Labs I decided to fork Scally so I could maintain it myself under my own personal GitHub account.
FAQs
Unknown package
We found that scally-test demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers found several malicious npm packages typosquatting Chalk and Chokidar, targeting Node.js developers with kill switches and data theft.
Security News
pnpm 10 blocks lifecycle scripts by default to improve security, addressing supply chain attack risks but sparking debate over compatibility and workflow changes.
Product
Socket now supports uv.lock files to ensure consistent, secure dependency resolution for Python projects and enhance supply chain security.