-
Notifications
You must be signed in to change notification settings - Fork 86
Description
After staring my work on #265, I realised that merging that work into 1.x is too risky regarding backward compatibility, due to #201. The existing array-based value API is less type-capable than the new API (see #296 for instance), so we need to refactor the Environment to use the Value objects to store variables. This will break BC for child classes messing with the internals of the Compiler.
Suggested roadmap
Note, when I give versions like
1.x, it means a minor version in the series, with the exact version number depending on which this gets released. Not everything might happen in the same minor release.
1.x
- add a deprecation warning when a
lib*method is detected as the implementation of a function and it comes from a child class (asking to useregisterFunctioninstead) - tag all protected functions as
@finaland@internalso that child classes using them or overriding them get a warning in the IDE - do the same for public methods that should not be needed for implementing custom functions and don't need to stay public (for instance, this does not include the
Compiler::assert*helpers as custom functions need them). - mark public helpers as
@finalso that child classes get an IDE warning when overriding them - tag classes as
@internalfor all classes that should not belong to the public API (this includes theParserclass to me)
2.0
- remove color math (which is already deprecated since 1.4.0 and is gone entirely in dart-sass)
- remove deprecated APIs of the Compiler
- remove deprecated formatters (this will unlock rewriting the way we produce CSS in a more modern way as we won't have to deal with these old styles)
- change all protected APIs of the Compiler to
private(as well as public internal methods that don't need to stay public) - change all
@finalpublic methods of the Compiler to actually be final
The 2.0 release is intentionally kept small in scope so that it can happen fast after the final 1.x release, to avoid maintaining 2 branches in parallel for a long time.
2.x
- implemented typed value objects (Values as typed objects #265)
- rewrite the scope handling to store variables as typed values
- update
registerFunctionto support registering a function as using the modern value API (and deprecate registering functions with the old API) - etc...
Over time in 2.x, we can rewrite parts of the library (see #193) freely, as almost everything will be internal and so won't impact backward compatibility.
And hopefully, after some time, we will have a 2.Y release passing sass-spec.
Suggested process
- implement the 1.x changes
- release 1.x
- create a
1.xbranch - change the
masterbranch alias to2.x - clean deprecated APIs
- do the 2.0 release
- from that point, the
1.xbranch enters maintenance mode, where only critical bugs get fixed (any sass compliance work happens in 2.x with the more modern API) - keep working on modernizing scssphp
As such, the 2.0 release is expected to happen soon.
Projects that don't use deprecated APIs should be able to migrate quite easily.