Allowing piping of generated CSS mapping into subsequent operations

[jpeer264]

Allowing piping of generated CSS mapping into subsequent operations

[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 🙃