I'm working on the SAAS product with the client customization. Basically, we keep one SCSS entry point for generic styling and want to keep an additional entry point per brand. The problem is when I define an array in the angular.json it compiles all into the single css file. I want to have a file with generic css and a css file per client. Is it possible to do with angular-cli?
Basically, I found the answer myself. It's possible to use the following syntax in the angular.json:
"styles": [
"src/styles.css",
{ "input": "src/pre-rename-style.scss", "bundleName": "renamed-style" }
],
Here is the link to documentation: https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/global-styles.md
Update 2020: use option "inject: false" if you want to tell the Angular CLI to NOT include the styles right away if you want to include them later. Older versions of Angular use "lazy" instead of inject.
"styles": [
"src/styles.scss",
{
"input": "src/styles/themes/dark.scss",
"bundleName": "dark",
"lazy": false
}
]
Related
I am putting Tailwind in an Angular project. I have what I think is the most standard configuration (default one, only changed the colors) :
tailwind.config.js
module.exports = {
content: [
join(__dirname, 'src/**/!(*.stories|*.spec).{ts,html}'),
...createGlobPatternsForDependencies(__dirname),
],
theme: {
[...]
},
plugins: [],
}
Yet, I face problems when I use a CSS class for the first time. For example mt-10.
It seems that tailwind uses the glob pattern to detect the used css properties and create a CSS on the flight when the server starts. Is that correct ?
If I understand it correctly, it seems to make sense in order to avoid having a huge CSS file with tons of properties that are not used.
But it means that if I don't use this class at the moment I start the server, then it won't be available after a live reload. If I want to use a css class for the first time, it seems that I have to restart the server to have it detected before being able to use it, which is irritating.
Is it possible to deactivate this behavior in development ? It seems to me that it should be possible to build the huge CSS once for all in dev. Is there an option for that ?
I'm using TailwindCSS, I want a separate stylesheet CSS file for each of my web pages. like
about.html - about.min.css
portfolio.html - portfolio.css
First you should ask yourself why do you want to do this? Creating a separate style-sheet for each individual page (home, about, etc) is not really common. The focus is on re-usability and possibly only adding additional styles.
If you are concerned about the file size, then do not integrate Tailwind via CDN but build your own style. Then you have access to the purge function. Purge kicks out all unused styles and the result is a very small CSS file.
You can use:
const mix = require('laravel-mix')
mix.postCss('input.css', 'output.css', [
require('tailwindcss')`enter code here`('./tailwind.config.js'),
require('autoprefixer')
])
.postCss('input.css', 'output-pdf.css', [
require('tailwindcss')('./tailwind-custom.config.js'),
require('autoprefixer')
])
You'll need to install TailwindCSS as PostCSS plugin as well as postcss-import and autoprefixer. Then create postcss.config.js in root directory and add:
module.exports = {
plugins: {
'postcss-import': {},
tailwindcss: {},
autoprefixer: {},
}
}
then you can add as many css files as needed in your css directory, albeit with some concerns following this documentation
Keep in mind, you should only use one css for all pages in your web unless you have multiple projects with different styling required.
If you want multiple CSS output , then you should not be using Tailwind for your project.
I'm building out a custom WordPress theme with Tailwind and compiling assets with Laravel Mix 6.
In my tailwind.config.js file I have the following purge configuration:
purge: {
enabled: true,
content: [
'./assets/**/*.{.js|.scss}',
// './*.php',
// './*/*.php',
// './*/*/*.php',
],
safelist: [
// list any Tailwind classes which should never be purged, for example classes added via WordPress which are stored in the database
// 'classname',
],
},
Now, my first line works absolutely perfectly. It looks for any .scss or .js files inside my assets folder or subfolders and compiles on change. However if I uncomment any of the .php lines Laravel Mix constantly recompiles in the terminal even when I'm not making changes - it's completely endless.
I've narrowed the issue down to these lines, if they're not added it works fine, but I need them added so TailWind knows what classes are being used.
My webpack.mix.js for reference also:
const mix = require("laravel-mix");
mix.js("assets/js/main.js", "build/scripts.js")
.sass("assets/scss/main.scss", "build")
.sourceMaps()
.browserSync("wordpressthemedev.local")
.options({
processCssUrls: false,
postCss: [
require("postcss-import"),
require("tailwindcss"),
require("postcss-nested"),
require("autoprefixer"),
],
});
Additionally, if I do this:
purge: {
enabled: true,
content: [
'./assets/**/*.{.js|.scss}',
'./parts/**/*.php',
'./functions/**/*.php',
'./404.php',
'./footer.php',
'./functions.php',
'./header.php',
'./index.php',
'./page.php',
'./search.php',
'./single.php',
// './*/*/*.php',
],
safelist: [
// list any Tailwind classes which should never be purged, for example classes added via WordPress which are stored in the database
// 'classname',
],
},
Mix doesn't compile forever and does run fine, but I would rather avoid having to declare every PHP file at root level if possible
So, annoyingly there doesn't seem to be an easy way around this. As Myself and Amar highlighted, you can get around this if you explicitly set the names of the files within the purge array - but this isn't the most optimal solution especially if your implementation has a lot of files to check.
I did some extra digging, and if you're trying to use this with WordPress, I could really recommend starting with either Roots Sage or MountainBreeze on a Roots Bedrock installation.
I personally find Sage a little too bloated out with unnecessary functions for most of the sites I build, so I'm running with Bedrock & MountainBreeze - A really nice combo so far!
I am trying to import the .css from full-calendar package.
First, I created a new component my-calendar (html, scss, ts).
Then, I tried 3 different ways but only the last one worked for me:
Reference the file directly, as the documentation suggested, in the index.html (it does not work because the reference to node_modules is lost when you build the project)
<link href="node_modules/fullcalendar/dist/fullcalendar.min.css" rel="stylesheet">
Adding #import "~fullcalendar/dist/fullcalendar.min.css"; in my-calendar.scss. If I am not wrong, this should add the style into main.css when the project is being built (is not working)
Create custom copy config (copy.config.js)
module.exports = {
...
copyFullCalendar: {
src: ['{{ROOT}}/node_modules/fullcalendar/dist/fullcalendar.min.css'],
dest: '{{BUILD}}'
}
}
and adding #import "fullcalendar.min.css"; into my-calendar.scss
UPDATE:
and adding #import "fullcalendar"; into my-calendar.scss
to avoid compiler errors when use ionic build --aot --minifycss --minifyjs
I would appreciate if someone could clarify the best way and explain if I misunderstood some concept.
PS: Remember that I am working with Ionic3 and I am not using the Angular CLI.
third method of yours will be the best way to implement , but it can be done in another way more like ionic.
You need to make use of the includePaths when configuring the custom path , as we are dealing with custom css, add sass.config.js to local project folder where we configure custom includePaths like this
includePaths: [
....
'node_modules/ap-angular2-fullcalendar'
],
In package.json scripts to include custom css configuration file, like this:
"scripts": {
.....
"ionic:serve": "ionic-app-scripts serve -s ./config/sass.config.js"
},
Only problem with this implementation is when you update ionic-app-scripts you have to compare the native sass.config.js file to the local file and check if there is anything changed.
This is a troublesome method and an issue was raised in Github but unfortunately they closed the issue with the following justification
Configs are extended, so only include the fields that you're changing.
Everything else will inherit the defaults.
As of #ionic/app-scripts : 3.2.0, it seems you'll still need to
#include FILE; somewhere
See this closed issue on app script's github
I found that as of
'Ionic Framework : ionic-angular 3.9.2'
you have two choices insert your import in src/theme/variables.scss or src/app/app.scss.
For example in variables.scss
/* some declarations here */
#import 'insrctest';/*file sits in src/test/insrctest.scss*/
And in my custom.config.js
includePaths: [
'node_modules/ionic-angular/themes',
'node_modules/ionicons/dist/scss',
'node_modules/ionic-angular/fonts',
'./src/test', /* when the import above gets called, node-sass will look in here */
I am using a MediaWiki wiki with custom skin. Now I see the CSS code of my custom skin overridden by the CSS code of MediaWiki itself.
How can I change the order of loading CSS code?
There does not appear to be a straightforward method to loading your CSS after the MediaWiki styles, as it is loaded by the primary resource loader via load.php on your page (View source on your web page to see your resource names listed first, generally, e.g. ext.MySkin.styles as outlined below), but I have found a solution which worked for me.
Within your skin.json or extension.json (or your PHP code) you can add a "group" field with the value of "site" to load your extension stylesheet after the main CSS for the site has been loaded.
For example, in your skin.json or extension.json:
{
"name": "MySkin",
...
"ResourceModules": {
"ext.MySkin.styles": {
"styles": [
"my-skin.css"
],
"group": "site"
},
"ext.MySkin.js": {
"scripts": [
"my-skin.js"
]
}
},
...
}
Check out the documentation for $wgResourceModules as well as the Group definitions which is linked there as well.
MediaWiki will load your extension/skin styles as a 2nd page request which is not optimized, but it will work in this application as you desire and your CSS will overwrite previous values within the skin, so for most applications this is appropriate, and works.