[Proposal] publish a sass-types package with type declarations for the standardized JS API #4037
Labels
Comments
|
This seems reasonable to me. We'd have to do a fair amount of work to get the release infrastructure working for it, though. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This repo contains the source code for type declarations for the JS API, as the JS API is standardized between
sass-embeddedandsass(andnode-sassfor the legacy API). those files are then copied in the npm packages being built forsassandsass-embedded, which is how they are consume.This works fine for projects installing a specific implementation and wanting type checking for using it. However, it is painful to write type declarations for a package compatible with any implementation of the standard JS API. And nowadays, most build tool or bundler plugins handling sass are in that category to allow projects to decide whether they want to use
sassorsass-embedded.For instance, I want to contribute to DefinitelyTyped to provide the type declarations for
gulp-sass6.0 in@types/gulp-sass. The version 5 depends on@types/node-sassto get the type finition of the legacy API (which is already incomplete as it is an old version of the legacy API). this makes my project install@types/node-sasseven if I don't use node-sass, but that only a few KB so that's not a big issue. But as sass now ships its type declarations directly in the package, the direct implementation today would require depending onsassinstead. If a project usessass-embedded, this would make the project install bothsassandsass-embedded, which would be wasting a lot more space.It would be great to publish a type-only npm package for the JS API (basically, publishing the
js-api-docfolder of this repo, with a different readme file aimed at the package page rather than spec contributors). This way, such plugin loader could depend only onsass-types(or@sass/typeseven though existing packages don't use a@sassnamespace).This
sass-typespackage would be published with version in sync withsassandsass-embeddedfor simplicity. Thanks to the way they are managed, functions exported fromsasswould satisfy the types defined insass-typesand so would be usable with a plugin usingsass-types(except for theNodePackageImportertype that relies on a unique symbol hack to distinguish the exact class being used, but this is on purpose actually: someone usingsass-embeddedmust use theNodePackageImporterofsass-embeddedand not the one ofsass, but that's not the kind of things you would need for the code of a generic plugin anyway).this approach is what babel does with
@babel/typesfor instance, having a type-only package exporting types that are depended on by the various babel plugins. It is also done by@jest/types,@typescript-eslint/typesorundici-types(and probably others that I don't have in the dependencies of my work project where I found those examples)What do you think about that ?
The text was updated successfully, but these errors were encountered: