-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate external stylesheets #1304
Conversation
17b9c95
to
b72d8a3
Compare
@colinskow I used a different take on this. I used a convention to identify global SCSS files: Then a loader:
Now all This is of course not a separate file for styles but it differentiates between global and component local styles. Now, for having styles in a separate file, this is something I think the developer should decide. I think we should put the extract plugin to target 1 file, all other files the dev wants to include he should import from that main (and not from JS code). If he imports from JS code it goes to the head. My reasoning about this is that if all styles are in 1 directory it's far more logical to import them all from one file inside that directory, similar to an I see this directory as the I have a problem with style imports scattered around the project, it's hard tracking their order and that's important for CSS. |
The order of the CSS will be the order the files were imported. I've created a styles directory where all the external styles will originate, and I think we should leave it to the developer to choose a convention. They are not scattered around the project, except for the Angular component styles which are inlined with the JS. I library like Bootstrap can be imported by putting a file in the styles directory and using @import. |
@d3viant0ne it doesn't appear we have any disagreements with this PR. @shlomiassaf suggests using the naming convention I suggest we merge this so I can start working on other enhancements like DLLs without having to rebase. |
1.) Rebase it. 2.) As far as conventions go, they are much like words in scrabble. In this case, I think it would be best to not enforce conventions on people. If a developer wants to do something like @shlomiassaf is suggesting, they can extend the project as they see fit. The most common way I have seen / used in regards to scss and 3rd party styles would be to use Keep it simple & let the developer make his / her own decisions on conventions. |
Rebase completed. |
In production apps it is a bad practice to inline large CSS files to Javascript, as it can slow initial page load and cause unstyled HTML to flicker.
This PR adds the ability to put SASS or CSS files in the
./src/styles
directory, import them into a module, and they will generate an external CSS file on production builds. On dev builds they are imported using thestyle-loader
to support hot module reloading.