I've configured stylelint to read SCSS and I keep getting browser hack warnings on SCSS items like $variables and !default. I loaded in the stylelint-scss plugin thinking this might fix it but it hasn't. I want the browser hacks rule to be enabled for true browser hacks but I'll have to turn this off if it fails on all of the SCSS items.
Does anyone know how I can keep the browser hack rule enabled but not have it fail on non-browser hacks like the standard variables for SCSS?
The no-browser-hacks rule is not compatible with SCSS syntax. This is documented in the rule's README.
I can think of three options available to you:
Continue to use SCSS and turn off the no-browser-hacks rule.
Continue to use SCSS and contribute SCSS compatibility to stylehacks (the underlying library that powers the rule). The author of the library is happy to accept a Pull Request for this.
Discontinue using SCSS in favour of using standard CSS syntax and constructs.
Adding the stylelint-scss plugin will not resolve the issue as it provides additional rules specific to SCSS syntax and constructs. It does not change stylelint's core rules.
Related
I have LSP and LSP-typescript packages installed.
I also have directory with typescript code snippets (read: gists), which i sometimes open with sublime. When i interact with such a snippet, i usually get some typecript syntax warnings, coming from LSP. Incorrect syntax in this case is OK of course, because snippets are examples with unmet dependencies, missing constants etc...
Is there an option to disable LSP in such directories where I do not want any checks to be performed?
Apparently it is not possible to exclude directories, but you can achieve something similar by creating new project and disabling chosen LSP-clients at project level. It is doable via command palette => LSP: Disable language server in project.
I was used to using the 7-1-pattern to structure my Sass codebase.
Now I started analyzing my project with Google Lighthouse, and basically it tells me that I should removed my unused CSS. The unused CSS however is there because I include my main.sass, which includes all styles independently from the page I'm on.
How do you guys usually deal with this? Page-specific imports (breaking the 7-1-pattern) or are there other tweaks?
I am trying to set up sass with Angular Dart but I'm a bit lost and couldn't find a documentation past 2016 (a good one)
I currently have the following structure:
However I cannot reference a main.css file as it is not found and if in a component I put something like this
styleUrls: ['lib/assets/sass/main.scss']
The webdev serve command fails
My pubscpec is
dependencies:
angular: ^5.0.0
angular_components: ^0.9.0
bootstrap_sass: any
dev_dependencies:
angular_test: ^2.0.0
sass_builder: ^2.1.1
build_runner: ^0.10.0
build_test: ^0.10.2
build_web_compilers: ^0.4.0
mockito: ^3.0.0
test: ^1.3.2
I cannot figure out what's wrong and also the structure I should use
Should I put in my top component main.scss (or the compiler main.css) and do not set any other file reference or should I include it at every component? And also how can I generate this compiled file when I run webdev serve
Thanks,
Alexi
So the references for styleUrls should always be the compiled css not the Sass file. Also the Urls need to be either relative to the file, or package format. So either 'main.css' or 'package:your_project/assets/sass/main.css'
I would also suggest not having separate asset directories. I tend to find having the sass file next to the component to be easier to maintain.
AngularDart also has style encapsulation by default; meaning CSS won't leak outside of the Components by default. Given this I find it better to have the CSS local to that component and be next to that component. You'll find that is the pattern on the angular components, and gallery.
One small note on the components, and gallery. They use the pattern style.scss.css instead of style.css which breaks the convention of Sass. The reasoning behind it is so that we can quickly tell what the source of the CSS file was. Was it written by hand, or did it come from Sass. This is achieved by having different settings in the build.yaml file. I don't think you should do this for your project tho.
Is there a way to sort my #include statements in Clion? Additionally, can I do this automatically every time I save? I didn't manage to find any such functionality or plugin.
Yes, it is possible with help of clang-format.
File->Settings...->Languages & Framework->C/C++->Clangd->Enable clangs server
clang-format should be installed in your system. Normally it is available in your favourite repository. You can specify the path to it if required
File->Settings...->Tools->clang-format
You have to put .clang-format file into your project root with coding rules. More information you can find on clang-format web site. For example, I am using Google coding rules. My content looks like this:
Language: Cpp
BasedOnStyle: Google
This includes already the include statements sorting. However, there is a choice of other ready-to-use coding styles like LLVM, Mozilla, WebKit, Chromium which you can use and if necessary modify or you can create your own format by providing set of rules you want. The rule you might be interesting in is
SortIncludes (bool)
If true, clang-format will sort #includes.
Please refer to the clang format documentation here
I've run into a rather annoying issue.
We have a very large code base which is mostly legacy code, and we have just begun implementing bootstrap. We have to "namespace" or "wrap" the bootstrap code in a class so that we can apply bootstrap to only parts of a page without affecting anything else.
If you're familiar with this technique, the common workaround is this:
.bootstrap-wrapper {
#import (less) "bootstrap.css";
}
See this issue: https://github.com/less/less.js/issues/1709
This works great as long as bootstrap.css is not minified. For whatever reason (probably something to do with semicolons), the minified version is not valid less even though it is valid css, and the less compiler errors out.
This wouldn't be much of an issue, except we are using Web Essentials (for VS 2013 update 4) to automatically compile our less into minified css files, and there is no granularity whatsoever.
We have the option to compile the unminified css files turned off, because we have no use for them, and only need the minified files. Since Web Essentials is all or nothing, there's no way for me to compile the unminified file in just this one case. We would have to carry an extra css file for every single compiled less file just to support this one case.
Are there any alternatives to creating a wrapper class this way, or is there anything I can do with Web Essentials to make this work?