Open xzyfer opened 8 years ago
:+1: on creating a separate sass-types
package, for JS interop (not C++). Would this have the same API as currently exists in Node-Sass?
Would this have the same API as currently exists in Node-Sass
Yes. The first iteration would simply be moving the existing code into a new package. We would also maintain BC by depending on that package to replace our current sass types.
The intent being users can write custom functions and importers using sass types without depending on node-sass.
:+1: And I also like @saper's idea of using Sass types as JavaScript classes. With sass types as separate package (and perhaps separate repo), we can even engage TypeScript to reflect the exact C++ types with ditto relationships (for time being☨).
I myself am working on LibSass.net (indulgently) using P/Invoke (FFI), as opposed to the current CLS binding wrapper (same as node-sass), where I am planning to support managed (.NET) types for consumer land and then instead of marshalling them as Sass types, I will use (P/Invoke) LibSass API functions (such as sass_make_map
and sass_make_null
et al.) to generate the Sass objects' pointers and pass it along to LibSass.
☨ Once node.js will provide OOTB FFI support, we would be (officially - as opposed to package support) enabled to use the same approach in future and achieve this decoupling of type systems and overall more freedom / separation of concerns.
My first question is, what are everyone's favourite color handling packages? Something you'd like to use to to HSV manipulation etc. in JavaScript, once you get your values out of Sass or before you submit them to Sass (via custom functions for example)?
https://www.npmjs.com/search?q=color
https://www.npmjs.com/search?q=kolor
https://www.npmjs.com/search?q=colour
I don't want to mandate the use of the one and only package with node-sass, just pick one to experiment with the APIs.
There is current an peerDependency issue with sass types.
This has come up a couple times with regards to custom importers, and more broadly.
I want to centralise discussion on this idea in a single place.
I'd also like to hear thoughts from @chriseppstein @eoneill @davidkpiano with regards to the implications (if any) to their work on eyeglass and sassport.
To prevent a BC break we could alias the existing sass_types to the new
sass-types
package.