Dear Maintainer,

   * What led up to the situation?

I installed node-node-sass, and ran its installed binary node-sass.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Ran the command "node-sass". I tried running in different paths, with
different parameters, and on a different system, but the result was
the same.

   * What was the outcome of this action?

$ node-sass
/usr/share/nodejs/normalize-package-data/lib/fixer.js:138
      if (!(deps in data)) return
                 ^

TypeError: Cannot use 'in' operator to search for 'dependencies' in ../package.json
    at Object.<anonymous> (/usr/share/nodejs/normalize-package-data/lib/fixer.js:138:18)
    at Array.forEach (<anonymous>)
    at Object.fixDependencies (/usr/share/nodejs/normalize-package-data/lib/fixer.js:137:41)
    at /usr/share/nodejs/normalize-package-data/lib/normalize.js:32:38
    at Array.forEach (<anonymous>)
    at normalize (/usr/share/nodejs/normalize-package-data/lib/normalize.js:31:15)
    at meow (/usr/share/nodejs/meow/index.js:146:2)
    at Object.<anonymous> (/usr/lib/x86_64-linux-gnu/nodejs/node-sass/bin/node-sass:21:11)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)


   * What outcome did you expect instead?

Either no error message, or a more meaningful error message (in case I
used the command wrong).


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-node-sass depends on:
ii  libc6                 2.31-9
ii  libnode72             12.21.0~dfsg-1
ii  libsass1              3.6.4+20201122-1
ii  libstdc++6            10.2.1-6
ii  node-chalk            4.1.0-1
ii  node-get-stdin        8.0.0-1
ii  node-glob             7.1.6+~7.1.3-1
ii  node-globule          1.3.2-1
ii  node-gyp              7.1.2-4
ii  node-lodash           4.17.20+dfsg+~cs8.31.172-1
ii  node-meow             8.0.0+~cs3.21.0-2
ii  node-mkdirp           1.0.4+~1.0.1-1
ii  node-nan              2.14.2-2
ii  node-npmlog           4.1.2-2
ii  node-readable-stream  3.6.0-2
ii  node-source-map       0.7.0++dfsg2+really.0.6.1-7
ii  node-yargs            15.3.1+repack-2
ii  nodejs                12.21.0~dfsg-1

node-node-sass recommends no packages.

node-node-sass suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmBOfY4WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICG1dD/4v8dyYefhKc0hvITwf0sEz2BCs
yi5qcYMyXF4Xmi7svHJbyCiEdT6opxeO6tbtKxBf9+ct4QaaR0ooAp7v6MZRetN9
pFESYqH2UYTXRCGMctb3+8GM7LPGa7utY+Qdc+7yeNePtnltdji5O8A5yFPm3LxQ
fuziGVv8nJlpaG410YtJXEEUoZwX9sLNWNpL2JHYyYVzbL/3EHq7yB7L/6S6ihLW
ZeFYvib7Hn1ycycxIELdVgleh9pQmOZ7MRDGjmhmQpcWfP4KZRm0kXRb88d5l8sT
6OMjT2acZQyrlVgePas/HOLZWErONikyOVJnPRZxT0WQrY6r6UBUGjpOG1oa4OeH
lu02yZmTYfw/B8AUbm4tOZPtsN8zC/oR/qq6HoainKjj8oi1kgUb0mM8psahE73M
UtCM+JQLzPvAOS0e29v2t7RI6oKC6KxX9d0Ho3OpPe1pHbX+drxiuOVnBPsLvLmw
Ev6nwpmM4VJaSkVP/LewqUYmReRZQAa3+a+KFn1Ef0erz7gyGg4Ij+qyvtv/B886
QLbE7JhecOPBmPh5nUdDnQXWfl86mH/d3mCK9Hff729REuYQOQWQ75Qw/e/bf3b9
EEJzYb50zp/7cfy9mwJGRIjVfSX8DU9iQqSbrLRlxgmcgtdv3tCDOeAo71c6alkp
lU7UZnc8GpTCh/4fug==
=eA7E
-----END PGP SIGNATURE-----

Also maybe this bug should be reassigned to node-normalize-package-data?

@Team, thoughts?

Nilesh

If someone wants to use the binary and someone cares to make it work, we can fix it.

If no one steps in to fix this, then we can consider removing it.

Is node-node-sass using a compatible version of node-normalize-path?

May be it is expecting a different API? (If the version node-node-sass expects in its package.json is different from the version available in the archive, this can happen).

Hello,

Codesearch does not list any uses of node-sass binary. Thus I think it
is safe to remove it.

In package.json, node-node-sass does not mention neither
node-normalize-package-data nor node-normalize-path.

Best,
Andrius

ACK. This should be done after freeze, right?

Nilesh

It might not be a direct dependency but a transitive one.

Nilesh

Hi,

I would be better to not ship broken things in bullseye, and remove them
afterwards. I suggest removing it before bullseye, and re-adding in the
next point release.

True. I prefer leaving it for someone with appropriate knowledge to
investigate further.

Best,
Andrius

How? A command line interface can be used directly by users.

Isn't the command supposed to allow compiling .scss files to .css?

But I agree if no one is interested to fix this, removing may be the best option now.

If someone comes up to fix later, we can add it back.

I am by no means making any claims about usage of node-sass by the end
users. My point was that codesearch.debian.net shows no hits, thus by
removing node-sass executable we are not breaking any other package in
Debian, what would be detrimental during the freeze. Sorry if I was not
clear enough.

My opinion is that shipping broken executable should be a
release-critical bug. Thus if we want to have node-node-sass package in
bullseye, we should either fix node-sass executable, or not ship it at all.

I suggest doing the same.

Best,
Andrius