Feature - Global dependencies

[mrfr0g]

Global Dependencies

In the past I have setup applications to have a split, but mirrored file structure with JS components on one side, and their styles on another. That typically looks like;

• style/
  • all.scss
  • _variables.scss
  • modal
    • _modal.scss
• components/
  • all_components.js
  • modal
    • modal.js
• app/
  • app.js

In this model I have to resolves dependencies at three levels, all styles are @imported into 'all.scss', all componentes are included within 'all_components.js', and finally the app includes both 'all.scss', and 'all_components'. The trouble with this setup is that components aren't truely portable alone, i.e., I can't only include the 'modal.js' component and expect to receive all its functionality and style. My preference is to move to a model where that is possible, where I can include just 'modal' and not be concerned with the style the component requires. To solve that problem I've moved to a model where the component is organized with anything it needs to run. This includes tests, styles, and functionality. Taking the previous example,

• components/
  • _variables.scss
  • modal
    • modal.js
    • _modal.scss
    • tests/
      • modal-test.js
• app/
  • app.js
  • app.scss

The problem uncovered by this model is that 'modal' component has dependencies on the 'component-wide' _variables set. To include those, I would have to explicitly @import them for every new component I create. This would be repeated for any new 'component-wide' styles that were added later, like sprites, or layouts.

Proposed solution

Create a configuration option to inject global dependencies at run time. This would solve my problem, and would help to keep components in this type of structure clean and maintainable.

This PR exposes a new configuration option 'globalIncludes' which will map to @import statements at the top of each processed file.

  sassLoader: {
    globalIncludes: [
      './_variables.scss',
      './_layout.scss'
    ]
  },

Example output

  # _modal.scss
  @import "./_variables.scss";
  @import "./_layout.scss";

  # _app.scss
  @import "./_variables.scss";
  @import "./_layout.scss";

[jsg2021]

if you have placeholder selectors or @extend anything from a global dep, would it work as expected? (where the selector list that is extended gets appended and the body not duplicated?

ex:

in _variables.scss:

%icon-foo { background-image: url(...) }

in some component:

.button.foo {
  @extend %icon-foo;
  ...
}

and in some other component file:

.label.foo {
  @extend %icon-foo;
  ...
}

I would expect the output css would only have one instance of the background-image rule...where %icon-foo becomes: .button.foo,.label.foo

[mrfr0g]

@jsg2021 No, this pass doesn't take care of deduping across files. I suspect that's because of the way the scss files are processed by webpack. In this structure they are processed (and scoped) on a per require basis.

Taking your example;

• component1
  • component1.scss

.component1.icon {
  @extend %icon-foo;
}

• component2
  • component2.scss

.component2.icon {
  @extend %icon-foo;
}

Becomes

.component1.icon {
  background: url(...)
}

.component2.icon {
  background: url(...)
}

However if you included the @extend twice within the same file, it would behave as expected.

• component2
  • component2.scss

.component2.icon {
  @extend %icon-foo;
}

...

.some-other-component.icon {
  @extend %icon-foo;
}

Becomes

.component2.icon,.some-other-component.icon {
  background: url(...)
}

[mrfr0g]

@jsg2021 any more thoughts on this?

[jsg2021]

I like the direction. :) I've been wanting to split my scss up like this for a while. I don't have write access to this project. I'd be curious what @jtangelder thought of this.

[jsg2021]

I wonder if we can use the baggage-loader to accomplish this...

[jhnns]

@mrfr0g thank you for your pull request and sorry for the response time, I haven't found the time to review it yet.

What problem does this PR actually solve? I think it's a good thing to declare dependencies explicitly. We had global variables in the browser for a long time and I don't want to go back to this anymore. I think that a component should be truly self-contained. It should not expect global variables to be defined.

[mrfr0g]

@jhnns @jsg2021 Thanks for responding. To answer your question, the PR was meant to solve the issue of having something like a theme variables file, have it be included at the application level, and have those variables exposed to the rest of the require tree. Here is a diagram;

Application.js
--> variables.scss
--> component.js
----> component.scss

In this example since I'm including variables.scss within the application, I want them to be exposed to the rest of the child tree, specifically the component.scss scope. The PR solved this (poorly) by having a configuration option to include files like variables.scss automatically within components.scss.

I believe that I can accomplish the same result using the data option resolved in #216, or as @jsg2021 suggested, the baggage loader.

[jhnns]

I believe that I can accomplish the same result using the data option resolved in #216, or as @jsg2021 suggested, the baggage loader.

Awesome 👍 😀