v8 8.4 in Node 14.6+ changed the toString behaviour for sass.types

[nschonni]

• NPM version (npm -v): 6.14.8
• Node version (node -v): 14.12.0, but anything above 14.5.0 has this
• Node Process (node -p process.versions):

{
  node: '14.12.0',
  v8: '8.4.371.19-node.16',
  uv: '1.39.0',
  zlib: '1.2.11',
  brotli: '1.0.9',
  ares: '1.16.0',
  modules: '83',
  nghttp2: '1.41.0',       
  napi: '7',
  llhttp: '2.1.2',
  openssl: '1.1.1g',       
  cldr: '37.0',
  icu: '67.1',
  tz: '2020a',
  unicode: '13.0'
}

• Node Platform (node -p process.platform): win32, but all in CI as well
• Node architecture (node -p process.arch): x64, but all in CI as well
• node-sass version (node -p "require('node-sass').info"):
• npm node-sass versions (npm ls node-sass): 4.14.1

Upstream node issue nodejs/node#35365 was closed as a wont-fix, as the behaviour is a change in v8.
The solution seems to be set the @@toStringTag or https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/toStringTag

[xzyfer]

Does this mean the latest release doesn't work on the latest node 14?

…

On Sun, 27 Sep 2020, 12:21 pm Nick Schonning, ***@***.***> wrote: - NPM version (npm -v): 6.14.8 - Node version (node -v): 14.12.0, but anything above 14.5.0 has this - Node Process (node -p process.versions): { node: '14.12.0', v8: '8.4.371.19-node.16', uv: '1.39.0', zlib: '1.2.11', brotli: '1.0.9', ares: '1.16.0', modules: '83', nghttp2: '1.41.0', napi: '7', llhttp: '2.1.2', openssl: '1.1.1g', cldr: '37.0', icu: '67.1', tz: '2020a', unicode: '13.0' } - Node Platform (`node -p process.platform`): win32, but all in CI as well - Node architecture (`node -p process.arch`): x64, but all in CI as well - node-sass version (`node -p "require('node-sass').info"`): - npm node-sass versions (`npm ls node-sass`): 4.14.1 <!-- When encountering a syntax, or compilation issue: - Please note that we cannot backport fixes to old versions, so ensure that you are running the latest release https://github.com/sass/node-sass/releases - Search for duplicate or closed issues https://github.com/sass/node-sass/issues?utf8=%E2%9C%93&q=is%3Aissue - Validate with http://sassmeister.com/ that the code works with Ruby Sass, then open an issue on `LibSass` https://github.com/sass/LibSass/issues/new Sorry you didn't have the experience you expected. --> Upstream node issue nodejs/node#35365 was closed as a wont-fix, as the behaviour is a change in v8. The solution seems to be set the @@toStringTag or https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/toStringTag — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2972>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENSWBMV7IZN5P3O45V3WTSH2OTJANCNFSM4R3IONZA> .

[nschonni]

It still runs, but the the toString in the following now just returns [object Object], rather than [object SassColor] like it was previously, which is way CI was failing on 14.6 and above

      var t = sass.types.Color();
      assert.equal(t.toString(), '[object SassColor]');

I don't think this makes a real functionally difference for the runtime, except maybe some extensions or advanced usage.

If we can't figure out the fix, then the tests could possibly be disabled, but I think trying to find a fix would be a good idea first

[xzyfer]

Yeah sounds like the test is probably not useful in its current form. Happy to remove it.

…

On Sun, 27 Sep 2020, 12:32 pm Nick Schonning, ***@***.***> wrote: It still runs, but the the toString in the following now just returns [object Object], rather than [object SassColor] like it was previously, which is way CI was failing on 14.6 and above var t = sass.types.Color(); assert.equal(t.toString(), '[object SassColor]'); I don't think this makes a real functionally difference for the runtime, except maybe some extensions or advanced usage. If we can't figure out the fix, then the tests could possibly be disabled, but I think trying to find a fix would be a good idea first — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2972 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENSWEC4KRZJLEMUEEYFD3SH2P3DANCNFSM4R3IONZA> .

[nschonni]

Got a hint over on the node issue that lead me over to here https://hyperandroid.com/2020/02/12/javascript-native-wrappers-in-v8-part-i/
But I kind of hit a wall trying to understand v8::Isolate, which is one of the parameters of the v8::Symbol::GetToStringTag(isolate) call

[hyperandroid]

This call v8::Symbol::GetToStringTag(isolate) returns a Symbol object, which is how v8 will resolve the prototype object name. There's not much to it, this is how Symbols are built natively.
As you say, the runtime is not very concerned on object's toStringTag, it is more a human-side thing.
This native code is que equivalent of calling this in js (maybe a quick fix could be adding these calls in js for each object needing it):

Object.defineProperty(
  obj, 
  Symbol.toStringTag, { 
    configurable: true,
    value: ‘MyObj’
  });