Importing a %placeholder multiple times results in duplicate declarations in output. #2224

Closed
stephaniehobson opened this Issue Jan 10, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@stephaniehobson

I have a placeholder in a master file and several sub files which include it. Looking at the generated CSS output I see the extended class declaration duplicated multiple times.

_vars.scss:

%offscreen {
    color: #fff;
}

icons.scss:

@include vars;
.icon {
    font-family: iconfont;
}
.icon-fallback {
    @extends %offscreen;
}

utils.scss:

@include vars;
.pull-right {
    float: right;
}
.visuallyhidden {
    @extends %offscreen;
}

main.scss:

@include icons;
@include utils;

Result (main.css):

.icon-fallback,
.visuallyhidden {
    color: #fff;
}
.icon {
    font-family: iconfont;
}
.icon-fallback,
.visuallyhidden {
    color: #fff;
}
.pull-right {
    float: right;
}

I like including the dependencies within the files that depend on them. In this case I was able to work around it by just including _vars in main.scss. This seems like the kind of bug that could bite devs who don't pay a lot of attention to their complied CSS.

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Jan 10, 2017

Contributor

Every time Sass processes an @import statement, it literally includes the imported file in the resulting CSS—even if it's been imported before. Here you're importing vars.scss twice, so the %offscreen rule gets defined twice and extended twice.

We're working on a major overhaul of the import system that will address this issue among others.

Contributor

nex3 commented Jan 10, 2017

Every time Sass processes an @import statement, it literally includes the imported file in the resulting CSS—even if it's been imported before. Here you're importing vars.scss twice, so the %offscreen rule gets defined twice and extended twice.

We're working on a major overhaul of the import system that will address this issue among others.

@nex3 nex3 closed this Jan 10, 2017

@tfsimondouglas

This comment has been minimized.

Show comment
Hide comment
@tfsimondouglas

tfsimondouglas Jun 6, 2017

I know this is a closed issue, but for those who work like @stephaniehobson ( I do too ) try using https://www.npmjs.com/package/dedupcss-webpack-plugin. It made my day :)

I know this is a closed issue, but for those who work like @stephaniehobson ( I do too ) try using https://www.npmjs.com/package/dedupcss-webpack-plugin. It made my day :)

@7iomka

This comment has been minimized.

Show comment
Hide comment
@7iomka

7iomka Jun 28, 2018

We're working on a major overhaul of the import system that will address this issue among others.

Problem is urgent, What is the progress of the solution search, except for installing a third-party plug-in?

7iomka commented Jun 28, 2018

We're working on a major overhaul of the import system that will address this issue among others.

Problem is urgent, What is the progress of the solution search, except for installing a third-party plug-in?

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Jun 28, 2018

Contributor

@7iomka Sass language design and development is done almost entirely by one developer (me), and it's not my only job. Prioritizing what needs to be done when is complicated, and it may not always result in the work that's most important to you being worked on when you want it. That's a reality of any work that involves many people, and it's especially true for open-source software.

If this is particularly important to you, I strongly encourage you to contribute some of your own time and energy to make it happen. I'd be happy to work with you to figure out how to most effectively tackle the problem, and to review and improve your code to get it into a state where it's ready to land in the repo.

Contributor

nex3 commented Jun 28, 2018

@7iomka Sass language design and development is done almost entirely by one developer (me), and it's not my only job. Prioritizing what needs to be done when is complicated, and it may not always result in the work that's most important to you being worked on when you want it. That's a reality of any work that involves many people, and it's especially true for open-source software.

If this is particularly important to you, I strongly encourage you to contribute some of your own time and energy to make it happen. I'd be happy to work with you to figure out how to most effectively tackle the problem, and to review and improve your code to get it into a state where it's ready to land in the repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment