Question: Breakdown of unimplemented features?

[philip-peterson]

Hi there,

I saw there are a number of outstanding tests that aren't passing. As someone outside to the project, I would love to adopt the library and contribute, but I am wondering what the failing areas are, and what kind of work would be entailed to tackle the remaining parts of the test suite. Maybe the project can have some issues open for major areas of work to be done?

Thanks, Phil

[connorskees]

Hello! Thank you for your interest in this project.

That is a good idea! I think it might be best to instead create an "outstanding issues" megathread that lists all of the known compilation issues. Creating individual issues for all of them would be a lot!

To add context to the failing tests, roughly 1,600 of them come from @use, @forward, and the module system, which is currently only implemented in dart-sass. 80 come from incorrect error messages and a further 80 can be ignored as they result from a deficiency in the spec tests themselves.

That of course still leaves around 500-600 failing tests, but it is a lot less bleak!

[philip-peterson]

Great, looking forward to seeing the breakdown! Will look into the module system to see how complex it looks.

[connorskees]

@philip-peterson I've copied my personal list to https://github.com/connorskees/grass/issues/19.

[pickfire]

I think this could be closed.

[connorskees]

Unfortunately my computer restarted while I was writing a response here.

To briefly summarize what I had previously written

• grass should have a near-feature-complete implementation of the module system within a week or two, presumably putting it 1-2 years ahead of libsass in that regard
• there remains additional work that needs to be done for @media, @at-root, @keyframes, and @supports (the tests for these rules are also lacking)
• grass should be able to handle most realistic inputs, though there is still much fuzzing work to be done and todo!() is used somewhat liberally
• the output system needs to be entirely rewritten and is the next task after the initial MVP of the module system. this should enable us to add Sass frameworks to CI (blocked because there are too many differences related to newlines) and implement compressed output (@pickfire I am unable to mentor compressed output as I am not yet sure how I would like everything structured)

grass now works for the following frameworks (and presumably others),

uikit           --  https://github.com/uikit/uikit
bootstrap       --  https://github.com/twbs/bootstrap
bulma-scss      --  https://github.com/j1mc/bulma-scss
susy            --  https://github.com/oddbird/susy (tests)
bourbon         --  https://github.com/thoughtbot/bourbon
zurb foundation --  https://github.com/foundation/foundation-sites
sassline        --  https://github.com/jakegiltsoff/sassline
modularscale    --  https://github.com/modularscale/modularscale-sass
materialize     --  https://github.com/dogfalo/materialize

If you never use anything more complicated than what's inside these frameworks, there's a very good chance your Sass will compile!

A production-ready version of this library would compile all of these frameworks byte-for-byte to dart-sass.

Given this progress and the itemization in #19 of many of the known, smaller issues remaining, I am inclined to close this issue. Please feel free to reopen this one or create a new issue if you have any other questions.