TypeError: path must be a string

[Martii]

I stand corrected... we get this on production which is SunOS instead of ia32/64 on dev...

[02/22 18:47:09 MST][err] TypeError: path must be a string
[02/22 18:47:09 MST][err]     at Object.fs.stat (fs.js:681:11)
[02/22 18:47:09 MST][err]     at /opt/run/snapshot/package/node_modules/less-middleware/lib/middleware.js:36:8
[02/22 18:47:09 MST][err]     at Array.forEach (native)
[02/22 18:47:09 MST][err]     at checkImports (/opt/run/snapshot/package/node_modules/less-middleware/lib/middleware.js:35:9)
[02/22 18:47:09 MST][err]     at /opt/run/snapshot/package/node_modules/less-middleware/lib/middleware.js:276:13
[02/22 18:47:09 MST][err]     at Object.oncomplete (fs.js:107:15)
[02/22 18:47:09 MST][err]   binding.stat(pathModule._makeLong(path), callback);
[02/22 18:47:09 MST][err]   
[02/22 18:47:09 MST][err] fs.js:681

... which can cause continual server restarts. I've had to revert our snapshot pre less-middleware dep update for the time being until we figure this out. :\

See also:

• current implementation at /app.js#L108-L115

[Martii]

Happens on a hard-page refresh on our dev as well.

$ node app.js
GitHub client authenticated
GET / 200 425.363 ms - -
GET /redist/npm/font-awesome/css/font-awesome.min.css 304 1479.287 ms - -
GET /redist/npm/octicons/octicons/octicons.css 200 1478.840 ms - -
GET /css/common.css 200 1475.073 ms - -
GET /css/github.css 200 1473.006 ms - -
GET /redist/npm/jquery/dist/jquery.js 200 1471.529 ms - -
GET /redist/npm/bootstrap/dist/js/bootstrap.js 200 777.799 ms - -
GET /less/bootstrap/oujs.css 200 2292.086 ms - -
GET / 200 391.603 ms - -   ************ HARD REFRESH INITIATED HERE

fs.js:682
  binding.stat(pathModule._makeLong(path), callback);
          ^
TypeError: path must be a string
    at Object.fs.stat (fs.js:682:11)
    at /home/user/repo/git/oujs/martii/OpenUserJS.org/node_modules/less-middleware/lib/middleware.js:36:8
    at Array.forEach (native)
    at checkImports (/home/user/repo/git/oujs/martii/OpenUserJS.org/node_modules/less-middleware/lib/middleware.js:35:9)
    at /home/user/repo/git/oujs/martii/OpenUserJS.org/node_modules/less-middleware/lib/middleware.js:276:13
    at Object.oncomplete (fs.js:108:15)

---

Rechecked v2 upgrade doc for less and it still says that it's an array for our end. Thanks.

[Zoramite]

So, two ideas. The first is that for production you may consider using the once option to not check for changes to the files. That should speed up your production environment to not check the files for changes every time a css file is requested.

Second, I introduced a bug with there not being the correct structure for the imports of a less file. I am working on a fix for that right now.

[Martii]

Kewl... I'll retest this as soon as it's on npmjs.com. :) As far as not checking for changes to the file we don't have direct terminal/console access yet so we would probably need to have something in startup to delete any related .css created so I'd rather keep that dynamic for the time being... although when I restart the browser the cache is cleared already so I wasn't aware there was a distinction between a hard-refresh and an empty cache with dev.

[Zoramite]

2.0.1 is now on NPM if you want to test.

The idea behind the once option is that in production servers the less files that back the css should not be changing with each request (YMMV). So you can flag that it only needs to find and compile the less file once. This prevents a filesystem call for all the less files and imports to see if they have changed since the last compile of the css. Definitely speeds things up if you are not changing the less files with each request in production.

[Martii]

Seems to be working on hard-page refresh on dev... SunOS and our node provider is a wee bit picky/odd and we're going to be transitioning, soon I hope, to a newer provider.

Right now we client-side cache css but eventually we may kick on server side caching for this as you suggested... just depends on if this projects cache mechanism will always recreate .css files on script start (e.g. $ node app.js for us or $ node debug app.js ... our provider runs $ npm start which is a script alias based in our package.json). Still long-term testing a few things related to less. Jerone I think is twiddling with some other themes to get used to less. I'm relatively new to it as well. Thanks again for the speedy assistance... I'll twiddle in dev for a little bit more just to be sure with some client side activities then push to our production.