katiefenn / parker Goto Github PK

When using other analysis tools I often take advantage of assertions. For example using phantomas one can assert that the analysis "failed" when there are more than X number of HTTP requests total, or the CSS exceeds a certain number of bytes, etc.

Using assertions within Parker could be a nice way to control the growth of a CSS codebase. I'm looking at stats like "Total Important Keywords" or "Total ID selectors" — things like that.

Possible cons: it might get misused and people might be lured into a false sense of security (or even write code in weird ways to avoid making a certain stat rise).

Would this feature be worthwhile to anyone else? Are there other cons I'm overlooking?

parker -n path/to/styles.css

Returns the help feedback, as if the option I'm passing is -h

If I remove the option entirely, it runs fine, so i'm confident the path isn't the problem.

I'm on parker v0.0.8 and node v0.10.17. Any ideas?

Great project and great tool! Thanks for implementing this.

I am able to get metrics for the css in my project. This is good, but now that I have it, it's hard to know how to use it. In general, I understand that we want to use fewer identifiers per selector, and use fewer selectors per rule, etc. But what number is good? What metric values should a project be striving for?

Not all projects are the same, but I think that we can all agree that for 99.9% of projects, using 10 identifiers per selector is too much. I'm hoping to get more precise than that, though.

I'm not expecting a precise answer, but I am hoping to start a discussion.

These two selectors have the same specificity (jsFiddle):

[href="#main"] {
    color: red;
}

.link {
    color: green;
}

However, I think Parker is reporting [href="#main"] as being an ID. When running Parker over a stylesheet containing only the above CSS (abridged for brevity):

PARKER-JS
Total Stylesheets: 1
Total Stylesheet Size: 64
Total Rules: 2
Total Selectors: 2
Total Identifiers: 3
Total Declarations: 2
Selectors Per Rule: 1
Identifiers Per Selector: 1.5
Specificity Per Selector: 55.5
Top Selector Specificity: 101
Top Selector Specificity Selector: [href="#main"]
Total Id Selectors: 1
...

Since chrome removed CSS profiler from chrome canary (https://bugs.chromium.org/p/chromium/issues/detail?id=265486), it would be useful to have a feature to list all selectors and order them from biggest to small, like:

#page ul li.active
#page ul li
div button
.blue-link

When running Parker on our styles directory (which is admittedly rather large), I get a discrepancy between the "Total Stylesheets" metric and the actual count of CSS files.

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ parker . | head -3
PARKER-JS
Total Stylesheets: 244
Total Stylesheet Size: 787343

peterjmag@peters-imac ~/tmp/css-metrics/flattened
$ find . -name "*.css" | wc -l
     289

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ find . -name "*.css" -exec ls -l {} \; | awk '{sum += $5} END {print sum}'
1861232

(Note that I've flattened the directory for this test case in order to rule out directory depth issues.)

In this case, it's missing 45 files. Interestingly, this number is very close to the number of CSS files in this directory that are 10KB or larger.

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ find . -size +10k -name "*.css" -exec ls -Slh {} \+ | wc -l
      43

If I remove, say, 60 files at random from the directory and run Parker again, I get accurate results:

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ parker . | head -3
PARKER-JS
Total Stylesheets: 229
Total Stylesheet Size: 1476955

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ find . -name "*.css" | wc -l
     229

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ find . -name "*.css" -exec ls -l {} \; | awk '{sum += $5} END {print sum}'
1476955

Digging a bit further, it looks like there are some file read errors that are being silently ignored. After adding some quick and dirty logging (see my patch at https://gist.github.com/peterjmag/5ff386c821a6612c99ce), I get errors like these:

peterjmag@peters-imac ~/tmp/css-metrics/flattened 
$ parker .
(libuv) Failed to create kqueue (24)
{ [Error: EMFILE, open 'admintools.css'] errno: 20, code: 'EMFILE', path: 'admintools.css' }
{ [Error: EMFILE, open 'browse.css'] errno: 20, code: 'EMFILE', path: 'browse.css' }
{ [Error: EMFILE, open 'examples.css'] errno: 20, code: 'EMFILE', path: 'examples.css' }
{ [Error: EMFILE, open 'home.css'] errno: 20, code: 'EMFILE', path: 'home.css' }
{ [Error: EMFILE, open 'signup.css'] errno: 20, code: 'EMFILE', path: 'signup.css' }
[...]
PARKER-JS
Total Stylesheets: 244
Total Stylesheet Size: 787343

Perhaps Parker's just reading too many files at once? Some googling for "node EMFILE 20" led me to graceful-fs as a potential solution, so I'll try it out and submit a pull request shortly.

If you just run parker, you get

PARKER-JS

and it just hangs. I'm assuming it should report usage instead.

Parker has some dependencies listed in package.json that should either not be in there, or be in the devDependencies section instead.

• backbone - not used anywhere that I can see
• mocha - development dependency, not necessary for normal use
• chai - development dependency, not necessary for normal use

Generally you don't want to include things like test frameworks in the dependencies. They will be downloaded any time someone installs parker with npm install -g parker when really they should only be downloaded when you do npm install (or npm link) from the repository root.

Hi,

When I try to run Parker on a Ubuntu linux server (BitNami mean stack) I get the following error.
I tried installing the package global and local but without success..

Best, Dirk

I think this would be useful to see if you've ended up with ridiculous z-indexes! 👍

Running Parker on this crashes

section, footer, nav {
display: block;
}

with the following error:

return values.reduce(function (previous, current) {return previous + curre
^
TypeError: Cannot call method 'reduce' of undefined
at sum (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:158:19)
at aggregateSum (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:103:12)
at C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:82:35
at Array.forEach (native)
at Function..each..forEach (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\node_modules\underscore\undersc
ore.js:79:11)
at aggregateData (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:79:7)
at runMetrics (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:64:12)
at Parker.run (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\lib\Parker.js:28:16)
at onAllComplete (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\parker.js:33:34)
at onComplete (C:\Users\abhas\AppData\Roaming\npm\node_modules\parker\parker.js:28:17)


But the same code formatted inline like this doesnt give any error.

section, footer, nav {display: block;}


I'm not really into Node.js, but I'd like to see Parker integrated in my development workflow with Gulp along with CSSLint, Gulp-Sloc etc.

Hello,

Sorry if I am missing something somewhere but i didn't find if there are any ways to parse an external stylesheet with parker installed as a project dependency ?

I tried to get Parker working in a browser environment (even tried browserify), but did not have any luck. Filing this issue in case you may be considering adding this.

I have tried running Parker.js from both NPM and Git clone but each time I get:

parker.js style.css 
PARKER-JS

/Users/jamescowie/Sites/MyProjects/Parker/lib/Parker.js:32
    throw {'message': 'No valid stylesheet data supplied', 'name': 'DataTypeEx
    ^
DataTypeException: No valid stylesheet data supplied

When using the GitHub repo I can npm install to satisfy all package.json requirements. When piping the output from curl into parker it works as expected.

Hey, I ran your tool against the main CSS file of BBC's new responsive site. See the output here: https://twitter.com/simevidas/status/441716656214011904

I've noticed that the most specific selector is:

#locator #locator-search-container.disabled button #locator-submit

which is a needlessly specific selector (no need for 3 ID selectors) and BBC's team should probably refactor it to something simpler.

This gave me an idea: Find the most specific selectors in my code and try to simply them. Your tool could provide this information. Would be quite useful, I think. What do you think?

The existing local stylesheet usage should be enhanced by the ability to load stylesheets by directory and filename pattern:

parker css/

parker css/*.css

Just ran this on a file and got:

Top Selector Specificity Selector: Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing

which is obviously from a comment in the CSS file.

After installing the package, I tried running the command parker spinner.css but I got a reference error. Here is the full message:

fs.js:35
} = primordials;
    ^

ReferenceError: primordials is not defined
    at fs.js:35:5
    at req_ (C:\Users\DELL\AppData\Roaming\nvm\v12.16.1\node_modules\parker\node_modules\natives\index.js:143:24)
    at Object.req [as require] (C:\Users\DELL\AppData\Roaming\nvm\v12.16.1\node_modules\parker\node_modules\natives\index.js:55
:10)
    at Object.<anonymous> (C:\Users\DELL\AppData\Roaming\nvm\v12.16.1\node_modules\parker\node_modules\graceful-fs\fs.js:1:37) 
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Module.require (internal/modules/cjs/loader.js:1044:19)
    at require (internal/modules/cjs/helpers.js:77:18)

I have:
node v12.16.1
npm 6.13.4

Sass is being widely adopted and running metrics on CSS generated by Sass has limited use. Parker should support Sass and new metrics should be created to analyse the complexity of .scss files.

Suggested metrics:

• Max rule depth
• Total variables
• Total mixins
• Unique colours by variable name

We use an older version of jQuery UI which contains the following bit of CSS to hack some kind of fix for datepickers with IE6 and iframes.

.ui-datepicker-cover {
    display: none;
    display/**/: block;
    position: absolute;
    z-index: -1;
    top: -4px;
    left: -4px;
    width: 200px;
    height: 200px;
}

The /**/ when found inside a selector causes Parker to end without fully parsing the file. I tested both before and after properties and declarations, all causing the early end. Outside of a selector it handles the empty comment fine. Putting a space between the two asterisks also fixes the issue.

Easy enough to fix by just removing the comment, but will affect anyone using an unedited older version of jQuery UI (v. 1.8.13 in my case).

curl http://www.katiefenn.co.uk/css/shuttle.css -s | parker

to

curl http://www.katiefenn.co.uk/css/shuttle.css | parker -s

(tested Windows git bash).

It should be nice to see a measure of declarations per rule. It's a nice way to ensure you are keeping your rules small enough to be used in more than one place and to keep CSS modular.

CSS Wizardry wrote this:

Rulesets with lots of declarations are probably quite monolithic, and could/should probably be broken down into smaller composable responsibilities.

I'm pretty sure this is an issue on my computer only, but it doesn't make sense. I just installed Parker on a desktop mac and everything went fine. Tried to do the same on my laptop and i get "zsh: command not found: parker". I pasted in npm install -g parker on both of them and it says it installed correctly, but it's not working when I try to use it. Any ideas?

If a CSS file begins and ends with a comment, then the sum function's Array.reduce (line 174 of Parker.js) attempts to reduce an empty array.

Pretty much the same as your Sass support enhancement (#3) (just with LESS). :)

Thanks

I've got an older version of bootstrap.css and when I run parker on it, I get:

/usr/local/lib/node_modules/parker/lib/CssMediaQuery.js:11
queries = pattern.exec(this.raw)[1];
^
TypeError: Cannot read property '1' of null
at CssMediaQuery.getQueries (/usr/local/lib/node_modules/parker/lib/CssMediaQuery.js:11:35)
at /usr/local/lib/node_modules/parker/lib/Parker.js:46:31
at Array.forEach (native)
at Function..each..forEach (/usr/local/lib/node_modules/parker/node_modules/underscore/underscore.js:79:11)
at /usr/local/lib/node_modules/parker/lib/Parker.js:44:11
at Array.forEach (native)
at Function..each..forEach (/usr/local/lib/node_modules/parker/node_modules/underscore/underscore.js:79:11)
at runMetrics (/usr/local/lib/node_modules/parker/lib/Parker.js:38:7)
at Parker.run (/usr/local/lib/node_modules/parker/lib/Parker.js:29:16)
at stdinData (/usr/local/lib/node_modules/parker/parker.js:53:30)

Problem

When counting the specificity of a selector Parker does:

• count the number of ID selectors in the selector (= a)
• count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
• count the number of type selectors and pseudo-elements in the selector (= c)

correctly as specified by Selectors Level 3: 9. Calculating a selector's specificity.

Then it concats the thee numbers into a string which it then converts into an integer using Number object.

I feel this is fundamentally wrong approach.

Example

The result of such is that having the following CSS:

w v u t s r q p o n m l k j i h g f d c b a {
    color: black
}

.foo .bar a {
    color: white;
}

Parker would count specificity 22 for the first one and 21 for the second. And then it would write out:

Top Selector Specificity: 22
Top Selector Specificity Selector: w v u t s r q p o n m l k j i h g f d c b a

But, clearly, the second selector has higher specificity!

The problem is Number object transforms the string into a base 10 number. Whereas the above mentioned specification precisely states that:

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Proposed solutions

There are two solutions I am aware of:

Base 16 like

Use letters to represent digits larger that 9, forming a sequence: 0-9a-zA-Z. That is the first selector in the example would get specificity n. Base 64 uses almost the same approach (with different order).

This would only move the problem to base 62, which would be more usable and would be (IMHO) enough in the vast majority of cases.

Three separated numbers

Show the result as three (dot?) separated numbers, making the first selector specificity 0.0.22. This reintroduces the way CSS2 deal with this. Such solution is vivid and complete.

It would however introduce a question how to count specificity per selector and related metrics. Counting average for each part would resolve this. Maybe it would even carry more information, as I have no idea what Specificity Per Selector: 9.48506151142355 truly represents.

Hi, here is update of graceful-fs to version 4.1.11 in package.json.
Newer versions of node warns about graceful-fs is out of date.
Heres updated package.json

{
  "name": "parker",
  "description": "Stylesheet analysis tool for CSS",
  "keywords": [
    "css",
    "stylesheet",
    "analysis"
  ],
  "version": "1.0.0-alpha.0",
  "main": "parker.js",
  "dependencies": {
    "async": "~0.2.10",
    "cli-color": "*",
    "graceful-fs": "^4.1.11",
    "lodash": "^3.2.0",
    "minimist": "0.0.7"
  },
  "devDependencies": {
    "chai": "*",
    "mocha": "*",
    "sinon": "*",
    "sinon-chai": "*"
  },
  "scripts": {
    "test": "mocha --no-colors --reporter spec"
  },
  "bin": {
    "parker": "./parker.js"
  },
  "homepage": "https://github.com/katiefenn/parker",
  "bugs": "https://github.com/katiefenn/parker/issues",
  "author": "Katie Fenn",
  "repository": "https://github.com/katiefenn/parker",
  "preferGlobal": true,
  "license": "MIT"
}

Here's a test case: http://codepen.io/anon/pen/GEcmx

The CSS file contains 4100 rules, and 4101 selectors. 100 of those rules are nested inside two media queries.

Parker gives the following result:

PARKER-JS
Total Stylesheets: 1
Total Stylesheet Size: 140038
Total Rules: 4002
Total Selectors: 4003
Total Identifiers: 4005
Total Declarations: 4002
Selectors Per Rule: 1.0002498750624689
Identifiers Per Selector: 1.0004996252810392
Specificity Per Selector: 9.996002997751686
Top Selector Specificity: 10
Top Selector Specificity Selector: .redClass0101
Total Unique Colors: 0
Unique Colors: 
Total Important Keywords: 0

Looks like Parker evaluates the media query as a rule, but not the contents of the media query.

Hi !

Thanks for sharing & maintaining this tool.

In a project, we have a deep folder architecture.
Parker seems to only parse stylesheets that are directly in the CSS root folder.

Cheers,
Thomas.

@katiefenn CHANGELOG.md is broken. Can you provide a changelog in CHANGELOG.md and in releases (https://github.com/katiefenn/parker/releases) ?

Thanks.

If you run this in a git repo with a path to a file, it'll run parker on every version of the file from old to new.

export css=path/to/your.css
git log --reverse --oneline $css | cut -d ' ' -f 1 | xargs -n 1 -I {} sh -c 'git log -n 1 {} && git show {}:$css | parker && echo -----------------------------'

I'm concerning myself with CSS performance and in the course of this I've found parker.
Looks good on first sight but some great features are missing:

• evaluation of the result (highlight good and bad values, configurable) => #48
• Sass/SCSS support => #3

When I consider the last time a commit was made and the currently published version (0.x) I'm a bit afraid to spend time getting really familiar with this tool.

@katiefenn are there any plans to continue working on parker?