-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Produce .d.ts (typings) and externs (closure) for use by JS #13
Comments
@xzyfer Does node-sass have these that we can adapt? |
I'm not intimately familiar with how JS type declarations work. Is this something we should ship with the npm package? Does it need to be declared somehow? |
@nex3 So if you have exact same public API as |
@nex3 Sass types in node-sass are defined in https://github.com/sass/node-sass/tree/master/src/sass_types. Having them in C/C++ actually causes a decent amount of pain for distributing custom functions. Custom function packages (like eyeglass) end up with an awkward dependency on node-sass. There is some scattered discussion on what to do about Sass types moving forward. We're currently leaning towards defining Sass types as JavaScript prototypes (or ES6 classes), distributed in a separate package. The node-sass binding layer to LibSass will handle turning LibSass types into v8 objects. This way custom functions will only deal with JavaScript objects. |
For the folks who wonder how can we use
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"sass": ["node_modules/@types/node-sass"]
}
}
}
|
@cedx is step 2 actually required for most people? Modern TypeScript these days automatically looks in |
If dart already knows typings information, it would be better if it could itself automatically generate the |
@binki Yeah, step 2 is required because without it, the TypeScript compiler will look for folder |
Dart's notion of what the types are doesn't correspond cleanly to TypeScript's, especially since Dart Sass has to do some dirty tricks outside of Dart's type system to generate the right JavaScript API. Also, the typings already need to stay in sync between Dart Sass and Node Sass, so auto-generating them wouldn't provide much advantage. |
@cedx one option is yes to have it in the @types/folder (usually the easiest way) However, with typescript I believe 2.3+ will pull it in from where you specify from the package.json as well. Thus editors that use typescript definition files would also be able to find them this way. VS Code, JetBrains, even Vim with the Here's a link to the typescript documentation on it If the dart types were included in this repo (I couldn't find them) I think a good faith effort could be made to convert them until we figure out a better way. It can't be that far off. |
Again, Dart's notion of types are substantially divorced from anything TypeScript could understand. I think the best way to handle this for now would be to have a build step copy https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node-sass into the generated npm package. |
@nex3 I completely understand. I think the real thing here, is since we're doing it by hand anyway, is that having the Dart Types gives us a basis to go off of, with some trial and error involved, rather than guess work. I could probably reason about enough to get something put together with those types, but I don't know Dart to be able to glean it from source code. Where as the type definitions, however ever far off they may be, would at least consolidate knowledge into once place where I can simply look something up if i'm unsure and do my best to map it. Unless you are suggesting that the node-sass API directly maps the dart-sass API? |
That's right. Both JS APIs are identical. |
We shouldn't use type from node-sass.
|
FYI: @types/sass seems abandoned. I have a problem with DefinitelyTyped/DefinitelyTyped#32091 for year. |
Just a quick one, in regards to sass/sass#3067, as fibers seems to be dead now (ref), do I:
|
If we were going to continue using Fibers, I think the principled answer would be option 4. However, since it's dying and doesn't seem likely to be revived, I think option 3 is probably the path of least resistance. |
Hey @nex3, I noticed that v1.45.0-rc.1 has now been released. Are you planning on including a |
I'll see if I can throw something together using the type definitions from the language repo. |
No description provided.
The text was updated successfully, but these errors were encountered: