Unit tests:
With 975 spec tests and 32 unit written for various options, it takes about 6 seconds from CLI (and 20s from VS) to run 1007 tests with release configuration. 🚀
I will add some tests for custom importer, functions and headers later.
Other notes on tests:
More unit tests needed for the options.
Functional, integration and use-case tests would be nice additions too. There are couple of crucial scenarios pertaining to use-case and functional testing (reusing of SassType typed objects between multiple compilation calls and many others), which must be covered by test at some point. Some of such scenarios were discussed in #34. I will try to spend some time and come up with something useful.
Custom Plugins:
This feature still needs to be worked out. Point to ponder: should we take dependency on code composition model and make it MEF2 flavored flexible plugin provider or should we provide a dependency injector or something very rudimentary? We need some concrete use cases to produce quality.
Compiler and AST via API:
LibSass is exposing internal parser/compiler for down-streams. Those features can be investigated.
Returned result:
Currently SassResult object does not:
Throws exception but carries the error message as a payload. Would make sense to throw messages there.
Returns back the option object: this means when context is compiled, the compiler has the modified version of options object which contains the resolved paths etc. That was going to be a bit expensive op in terms of CPU cycles and mem-alloc, so I skipped it. We can probably add it and load it lazily when user asks for it via result object.
.NET Core support:
This is not too hard to achieve. I have surfaced almost everything that is required to bring the support. There are some grey areas around RID settings and building native binaries cross platform etc. but it is something many people have already done.
Sample web project:
Probably should be replaced by either MVC Core app (or just a custom TagHelp, e.g. from consumer's perspective: <sass file="path/to/blah.scss" precision="11" output-style="compressed" />) etc.
At the moment nothing else coming to mind. Its time to take a nap. 😪
Please release a beta version, so we can get some feedback. 👀
aviatrix
commented
8 years ago
Fix #34
Unit tests: With 975 spec tests and 32 unit written for various options, it takes about 6 seconds from CLI (and 20s from VS) to run 1007 tests with release configuration. 🚀
I will add some tests for custom importer, functions and headers later.
Other notes on tests: More unit tests needed for the options. Functional, integration and use-case tests would be nice additions too. There are couple of crucial scenarios pertaining to use-case and functional testing (reusing of
SassTypetyped objects between multiple compilation calls and many others), which must be covered by test at some point. Some of such scenarios were discussed in #34. I will try to spend some time and come up with something useful.Custom Plugins: This feature still needs to be worked out. Point to ponder: should we take dependency on code composition model and make it MEF2 flavored flexible plugin provider or should we provide a dependency injector or something very rudimentary? We need some concrete use cases to produce quality.
Compiler and AST via API: LibSass is exposing internal parser/compiler for down-streams. Those features can be investigated.
Returned result: Currently
SassResultobject does not:.NET Core support: This is not too hard to achieve. I have surfaced almost everything that is required to bring the support. There are some grey areas around RID settings and building native binaries cross platform etc. but it is something many people have already done.
Sample web project: Probably should be replaced by either MVC Core app (or just a custom TagHelp, e.g. from consumer's perspective:
<sass file="path/to/blah.scss" precision="11" output-style="compressed" />) etc.At the moment nothing else coming to mind. Its time to take a nap. 😪
Please release a beta version, so we can get some feedback. 👀