Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

Should we move sass_types into its own package? #1320

Open
xzyfer opened this issue Dec 27, 2015 · 4 comments
Open

Should we move sass_types into its own package? #1320

xzyfer opened this issue Dec 27, 2015 · 4 comments

Comments

@xzyfer
Copy link
Contributor

xzyfer commented Dec 27, 2015

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.

@xzyfer xzyfer changed the title Should we move sass_types into their own module? Should we move sass_types into their own package? Dec 27, 2015
@xzyfer xzyfer changed the title Should we move sass_types into their own package? Should we move sass_types into its own package? Dec 27, 2015
@davidkpiano
Copy link

👍 on creating a separate sass-types package, for JS interop (not C++). Would this have the same API as currently exists in Node-Sass?

@xzyfer
Copy link
Contributor Author

xzyfer commented Dec 28, 2015

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.

@am11
Copy link
Contributor

am11 commented Dec 28, 2015

👍
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.

@saper
Copy link
Member

saper commented Jan 3, 2016

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.

jiongle1 pushed a commit to scantist-ossops-m2/node-sass that referenced this issue Apr 7, 2024
Adds various performance improvements
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants