Feat(dictionary) Added new filter removePrivate

[silversonicaxel]

Description of changes:
This PR is intended to provide a new builtin filter functionality, called removePrivate, to allow to set a design token to private: true in order to avoid to be outputted in the distribution folder after the build process.

For example, having an initial source of design tokens like the following:

{
  'black': {
    'value': '#000000',
    'private': true
  },
  'aqua': {
    'value': '#00FFFF'
  },
  'white': {
    'value': '#FFFFFF',
    'private': false
  }
}

a potential scss output would be something like this:

$aqua: '#00FFFF';
$white: '#FFFFFF';

or a potential json output would be something like this:

{
  'aqua': '#00FFFF',
  'white': '#FFFFFF'
}

This PR is created as follow up of the discussion hold in this other PR #704 where the same feature was tried to be achieved with a different approach

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[silversonicaxel]

For visibility I tag @chazzmoney

[silversonicaxel]

Since you were interested, I tag also @crypt096, @caseybaggz and @didoo

[silversonicaxel]

I still need to improve the documentation. I'll try by myself tomorrow, but any tips are more than welcome.

[silversonicaxel]

Ready for review

[dbanksdesign]

Thank you for all your work on this! Just one minor thing with the example and we are good to go!

[dbanksdesign]

ah so clean ✨

[dbanksdesign]

Thanks!

[dbanksdesign]

Thank you for adding an example!

[dbanksdesign]

Thank you for adding unit tests!

[chazzmoney]

Thanks for doing this! It is really nicely done.

After @dbanksdesign changes are complete, I'm ready to merge this!

Nice work.

[silversonicaxel]

FYI
Someone raise here ( design-tokens/community-group#110 (comment) ) some doubts regarding this approach, preferring the use of the 'private' key, as in the previous PR where all started.

Personally I don't mind this approach, more than the previous one. Up to you!

[chazzmoney]

@silversonicaxel I don't this the filter approach is in opposition; in fact, it is a simple change to make the filter run by default if the standards body decides that is a good idea and then publish it as a breaking change.

However, the final point in that discussion (that "private" may be an overloaded term with multiple meanings), is maybe a good one, which I wrote a response to here.

Do we really want to use "private"? Or should we try and use a more explicit property name?

[silversonicaxel]

@chazzmoney I see your point, line is subtle. there are some options on the table I think.

in favour (and with a personal order preference) (I also believe that them all might be also overloaded with extra meanings)

• private sounds the best choice, clear in its meaning
• reserved could be enough clear, understandable
• secret particular word, but also probably clear
• hidden semantically I feel it slightly more confusing than the rest (hiding from what?)
• filtered or filteredOut also possible

not in favour (since it tackles the other set of design tokens to keep in, and not filter out)

• exported semantically good
• exposed semantically good
• visible semantically is not super clear

What do you think? @dbanksdesign also, your opinion?

[dbanksdesign]

LGTM!

I think because this is a filter and not changing core functionality and the filter name clearly says 'removePrivate' I am good with this change even if the spec goes a different route.