Skip to content

[RFC] Revised plan for 2.0 #310

@stof

Description

@stof

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 use registerFunction instead)
  • tag all protected functions as @final and @internal so 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 @final so that child classes get an IDE warning when overriding them
  • tag classes as @internal for all classes that should not belong to the public API (this includes the Parser class 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 @final public 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 registerFunction to 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.x branch
  • change the master branch alias to 2.x
  • clean deprecated APIs
  • do the 2.0 release
  • from that point, the 1.x branch 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions