Sass linting fails locating config

[hnla]

Although updated npm & installed this WP version of stylelint config when running it passes the .css linting but .scss linting fails: Error: Could not find "stylelint-scss". Do you need aconfigBasedir? and a heap of others, do we have a clue why failing for scss?

This may be something dumb I've done wrong however my process was fairly straightforward in running npm update then simply running the lint task with css passing for two files scss failing for reasons above.

[ntwb]

I've just tested this on Windows:

C:\Users\Stephen\Dev\buddypress\next-template-packs» grunt lint
Running "stylelint:css" (stylelint) task
>> Linted 2 files without errors

Running "stylelint:scss" (stylelint) task
>> Linted 1 files without errors

Running "jshint:grunt" (jshint) task
>> 1 file lint free.

Running "jshint:core" (jshint) task

   bp-templates/bp-nouveau/js/buddypress-activity-post-form.js
    317 |                    nonce  : BP_Nouveau.nonces['activity']
...
...

So it works for me, it starts erroring with the JSHint checks though they are expected.

Can you confirm a few settings for me please @hnla?

• What versions of NodeJS do you have installed? node -v

• What versions of NPM do you have installed? npm -v

• What is the output of npm list --depth=1

[hnla]

I updated Node but to latest stable: v6.10.2 NPM: 3.10.10

List: `+-- grunt@1.0.1

| +-- coffee-script@1.10.0

| +-- dateformat@1.0.12

| +-- eventemitter2@0.4.14

| +-- exit@0.1.2

| +-- findup-sync@0.3.0

| +-- glob@7.0.6

| +-- grunt-cli@1.2.0

| +-- grunt-known-options@1.1.0

| +-- grunt-legacy-log@1.0.0

| +-- grunt-legacy-util@1.0.0

| +-- iconv-lite@0.4.13

| +-- js-yaml@3.5.5

| +-- minimatch@3.0.3

| +-- nopt@3.0.6

| +-- path-is-absolute@1.0.0

| `-- rimraf@2.2.8

+-- grunt-check-dependencies@0.12.0

| +-- check-dependencies@0.12.3

| `-- lodash.clonedeep@4.5.0

+-- grunt-contrib-clean@1.0.0

| +-- async@1.5.2

| `-- rimraf@2.5.4

+-- grunt-contrib-cssmin@1.0.2

| +-- chalk@1.1.3

| +-- clean-css@3.4.19

| `-- maxmin@1.1.0

+-- grunt-contrib-jshint@1.0.0

| +-- chalk@1.1.3

| +-- hooker@0.2.3

| `-- jshint@2.9.3

+-- grunt-contrib-uglify@2.0.0

| +-- chalk@1.1.3

| +-- lodash.assign@4.2.0

| +-- maxmin@1.1.0

| +-- uglify-js@2.7.5

| `-- uri-path@1.0.0

+-- grunt-contrib-watch@1.0.0

| +-- async@1.5.2

| +-- gaze@1.1.1

| +-- lodash@3.10.1

| `-- tiny-lr@0.2.1

+-- grunt-postcss@0.8.0 extraneous

+-- grunt-rtlcss@2.0.1

| +-- chalk@1.1.3

| `-- rtlcss@2.0.6

+-- grunt-sass@1.2.1

| +-- each-async@1.1.1

| +-- node-sass@3.10.0

| `-- object-assign@4.1.0

+-- grunt-stylelint@0.7.0

| +-- chalk@1.1.3

| `-- stylelint@7.8.0

+-- load-grunt-tasks@3.5.2 extraneous

+-- markdown@0.5.0 extraneous

+-- matchdep@1.0.1

| +-- findup-sync@0.3.0

| +-- micromatch@2.3.11

| +-- resolve@1.1.7

| `-- stack-trace@0.0.9

+-- postcss-reporter@1.3.3 extraneous

+-- postcss-scss@0.4.1

| `-- postcss@5.2.16

+-- stylelint@7.10.1

| +-- autoprefixer@6.7.7

| +-- balanced-match@0.4.2

| +-- chalk@1.1.3

| +-- colorguard@1.2.0

| +-- cosmiconfig@2.1.1

| +-- debug@2.6.3

| +-- doiuse@2.6.0

| +-- execall@1.0.0

| +-- file-entry-cache@2.0.0

| +-- get-stdin@5.0.1

| +-- globby@6.1.0

| +-- globjoin@0.1.4

| +-- html-tags@1.1.1

| +-- ignore@3.2.7

| +-- imurmurhash@0.1.4

| +-- known-css-properties@0.0.7

| +-- lodash@4.17.4

| +-- log-symbols@1.0.2

| +-- meow@3.7.0

| +-- micromatch@2.3.11

| +-- normalize-selector@0.2.0

| +-- postcss@5.2.16

| +-- postcss-less@0.14.0

| +-- postcss-media-query-parser@0.2.3

| +-- postcss-reporter@3.0.0

| +-- postcss-resolve-nested-selector@0.1.1

| +-- postcss-scss@0.4.1

| +-- postcss-selector-parser@2.2.3

| +-- postcss-value-parser@3.3.0

| +-- resolve-from@2.0.0

| +-- specificity@0.3.0

| +-- string-width@2.0.0

| +-- style-search@0.1.0

| +-- stylehacks@2.3.2

| +-- sugarss@0.2.0

| +-- svg-tags@1.0.0

| `-- table@4.0.1

`-- stylelint-config-wordpress@10.0.1

-- stylelint-scss@1.4.4

[r-a-y]

I can confirm @ntwb 's findings. I'm also on Windows and get the same result as mentioned in https://github.com/buddypress/next-template-packs/issues/139#issuecomment-298227203.

[ntwb]

The last two lines were the ones I was hoping to see, in particular that last line:

-- stylelint-config-wordpress@10.0.1
 -- stylelint-scss@1.4.4

Can you try flushing the following:

• NPM cache with npm cache clean

• Delete the node_modules folder completely (Via Explorer should do the trick)

• Run npm install once again

[ntwb]

FYI: I've just committed basically the same change to BuddyPress Core:

https://buddypress.trac.wordpress.org/changeset/11546

Following an npm install for BuddyPress should also work 😄

[hnla]

Ok re-install worked - thanks.

I've just committed basically the same change to BuddyPress Core:

Cooll! however...

Via Explorer should do the trick

yep sadly it doesn't nor do any cli admin commands work to delete this monstrosity of nested paths, ended up having to delete manually via re-naming, massive waste of time.

Hope with the BP update the same isn't true and will be trying simply 'update' or just installing over, which sounds dodgy :)

I noted though that there is a npm package that handles deleting: https://www.npmjs.com/package/rimraf

Not sure whether this is an option to install for long suffering Window users?

On a sidenote: going to need to change the scss linting to lint the partial files as the file buddypress.scss is simply a series partial imports so pretty much a static file that will always pass as lint free.

[ntwb]

yep sadly it doesn't nor do any cli admin commands work to delete this monstrosity of nested paths, ended up having to delete manually via re-naming, massive waste of time.

I get that it's frustrating, it's harder than it should be and Microsoft have had years upon years to fix this and they haven't 😢

Updating to NPM 4.x will fix this, NPM 4.x installs the modules in a "flat tree" rather than a "hierarchal tree of doom" 😏

I noted though that there is a npm package that handles deleting: https://www.npmjs.com/package/rimraf

I'm not aware of a way to use RIMRAF within a project to get around this scenario as it would install RIMRAF in the same node_modules path you're trying to delete 🤷‍♂️

As noted RIMRAF can be installgloballylly via npm install rimraf -g and this will make available rimraf on the command line, typing rimraf node_modules will delete the entire node_modules tree

On a sidenote: going to need to change the scss linting to lint the partial files as the file buddypress.scss is simply a series partial imports so pretty much a static file that will always pass as lint free.

I'll take a look at this shortly 👍

[ntwb]

Closing this as this issue is now resolved

[hnla]

Updating to NPM 4.x will fix this, NPM 4.x installs the modules in a "flat tree" rather than a "hierarchal tree of doom" 😏

Love good news first thing in the morning :)

I'm not aware of a way to use RIMRAF within a project... in the same node_modules path you're trying to delete

A good point :) I'll install globally when I've a moment & see how effective it is.

I ticketed and committed a change to gruntfile just to let me run linting yesterday, please update as seen fit.