Allowing piping of generated CSS mapping into subsequent operations

[davewallace]

I'm not sure whether this feature would go into rcs gulp repo or here, because I'd use it in the context of having two methods available in this repo available.

I can think of two new ways in which I might want to combine both processCss() and generateLibraryFile():

1. As part of a Gulp chain, I might want to firstly call generateLibraryFile() . The output of this function might be modified by configuration options such as excludes. This would then be output as a mappings file, but also piped to the next Gulp operation, for example processCss(), which would then make use of the supplied mapping output from the first operation. The result from chaining both operations would be an output mappings file and a replaced set of CSS selectors (pre/suffixed, minified, or other)

2. Next, we might want to not chain the above two operations, and simply generate a mapping when keys contain all discovered selectors, the value for the key would be the intended replacement value. Because this file exists and documents the mapping, we could then modify the mapping in case a) errors were made, b) we want a slightly different values for n given keys. We might then reference this mapping for use in a call to processCss(). The result of this would be replaced set of selectors (pre/suffixed, minified, or other) based on a potentially manual modified mapping.

Sample from point 2. above might be (prefixed, not minified selectors):

.generateLibraryFile() -> ...creates renaming_map.js which contains:

var CSS_NAME_MAPPING = {
  '.btn': '.ui__btn',
  '.btn-group': '.ui__btn-group'
} ;

With the above, if I wanted to then manipulate that, eg;

var CSS_NAME_MAPPING = {
  '.btn': '.ui__btn',
  '.btn-group': '.ui__btn-collection'
} ;

I could do so, and then reference that mapping file in my next call to .processCss(), via an option.

[JPeer264]

Ah, you mean this mapping function. Yes actually it could be in every repo - this feature would be good for all of 'em. The library file was actually introduced to debug selectors if they already got minified for production.

Great idea! I originally had this idea too, but totally forgot this feature.

What do you think about putting those things into the config file .rcsrc? This could look like following (which was the original idea)

{
    "exclude": [
        "some-excluded-selectors"
    ],
    "mapping": {
        "btn-group": "btn-collection"
    }
}

Maybe mapping is a bad word for it. I also don't think that it would be a good idea to put prefixes or suffixes into this, as it would be hard to debug if the prefix will be changed. As you already saw I did not put btn into the mapping, because it will be the same just with a prefix, so there is no need to put it into it (would be less in the config file).

[davewallace]

An addition in .rcsrc would be a good idea - do you mean that keys/values present in .rcsrc in the form of mapping (or alternative name, perhaps override) or exclude would take precedence over anything generated by an unmodified output from .generateLibraryFile()?

If the addition to .rcsrc is not an exceptions/overrides based approach, then I imagine the mapping could potentially grow quite large if it was intended to contain the entire contents of a given set of selector replacements, for example with the mass of Bootstrap selectors I've been testing with.

[JPeer264]

would take precedence over anything generated by an unmodified output from .generateLibraryFile()

Yes, I would say so. But, override (that is a good name) would be, as you said, to large.

If the addition to .rcsrc is not an exceptions/overrides based approach, then I imagine the mapping could potentially grow quite large

Oh, true! I think I would drop the idea then to put the override into the .rcsrc. So after a bit thinking it might be a good idea to load an already generated library/mapping file with the function .generateLibraryFile( 'path/to/file' ) to ensure to load already renamed selectors and add new triggered selectors.

You think it might be a good idea to rename the method .generateLibraryFile() to .generateMapping or something like that?

[davewallace]

Yep, . generateMapping sounds like a sensible replacement :)

[JPeer264]

@davewallace I thought a lot about this function and came up with a slightly different solution. First you have to load the old mappings via .loadMapping and after everything is processed you can save the new generated file with .generateMapping.

Have a look at the usage

I hope it fits to your use case 🙃