npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

cm-scally

v0.2.0

Published

Campaign Monitor's fork of Scally. Scally is a Sass, BEM, OOCSS, responsive ready, CSS framework that provides you with a solid foundation for building reusable UI's quickly

Downloads

4

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Git

Maintainers

chris__pearcechris__pearce

Keywords

scallycssoocsssassbemresponsive

Readme

Campaign Monitor's fork of Scally. This fork is primarily for allowing CM's to make quick updates to Scally without having to wait for the main Scally version. The idea is everything we add to this fork will make it back to the main version via a Pull Request.

Contents

Branches

They're 2 main branches:

master

The master branch should never be worked on—it's only for rebasing the main Scally version and should always be up to date with it—steps to do that:

  1. git fetch --all
  2. git rebase [scally-remote-name]/master
  3. git push origin/master

[scally-remote-name] = the name of the remote pointing to the main Scally version, to set this up you do:

git remote add scally-public [email protected]:chris-pearce/scally-website.git

The master branch serves as a copy of the main Scally version in case anything is to happen to it.

working

The working branch is the branch we work on—well not directly as all work needs to happen on a feature branch which is a branch off the working branch (see next section).

We will always get merge conflicts with the following files when merging the master branch into the working branch:

  • package.json
  • .version
  • README.md
  • CHANGELOG.md

We should always keep the working branch versions—this is very important.

The steps to merge the master branch into the working branch and bumping the version number:

  1. git fetch --all
  2. git merge origin/master
  3. fix merge conflicts with 4 files listed above then git add .
  4. Update the version numbers in the package.json and .version files
  5. Update the CHANGELOG.md file with an entry of "Updating to latest main Scally version and bumping the version"
  6. git add .
  7. git commit -m "Merging main scally and bumping the version number"
  8. npm publish

Chris Pearce will take care of keeping the CM fork in sync with the main version and merging the master branch into the working branch just to keep this with one person.

Feature branches

All work needs to happen on feature branches branched off the working branch.

If there's a GitHub issue for the work you're doing then name your feature branch like:

issue-x

Where 'x' is the issue number.

Submitting new code

Before making a change to the CM fork hit up the other front end developers to see if it's a worthy change and in line with Scally's principles, architecture, and naming conventions. A good place for any discussion around this would be the Front-end Engineering room in HipChat and the Front-end working group.

It's important you have a good understanding of how Scally works before adding to the CM fork—there is plenty of documentation to help with that and a website on the way and asking questions to the other front end developers.

Pull Requests

Anything that needs to be merged to the working branch needs to be reviewed via a PR.

All PR's need to point to the working branch NOT the master branch!

PR format

Your PR title should use the same title as its corresponding GitHub issue but prefixed with the issue number e.g.

Issue #108: Remove style.scss and style.css from the repo and package json files

And in the PR description include:

This fixes #[x]

Where 'x' is the issue number. GitHub will offer an auto-complete menu as soon as you type '#' where you can choose the corresponding PR.

You should also add a comment in the GitHub issue linking to the PR.

If your work doesn't have a GitHub issue then provide a descriptive title and description.

Examples and Guidelines

For examples of PR's see Scally's main version closed PR's.

Some guidelines to look at:

Test files

To test your changes create test.html and test.scss files in the root, these files will be ignored by git.

test.html:

<!doctype html>
<html class="no-js u-s-p-huge">

  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>CM Scally testing</title>
    <link rel="stylesheet" href="test.css">
  </head>

  <body class="u-s-p-base">

  </body>

</html>

The contents of test.scss is the entire Scally framework, see.

Make sure your Sass compiles in both Ruby and LibSass:

  • Ruby Sass:

    sass --watch test.scss:test.css --style expanded

  • LibSass:

    npm install node-sass -g

    node-sass test.scss test.css

Putting updates back to the main Scally version

If we decide an update should go back to the main Scally version—which in most cases it should—then we'll do this by issuing a PR to the main Scally repo.

The PR should be created by the author of the update using the feature branch the update was done on, following these guidelines.

NPM Package

This fork is available as an npm package: cm-scally so we can easily use Scally in the CM app's.

You include the npm package in the app's package.json file and to get the latest version use npm update cm-scally.