grunt/compass exclude files from compiling - magento

I'm currently developing a magento theme. I'm using grunt-compass and grunt-watch to compile my scss files. I would like to speed up the process with excluding styles-IE8.scss for compiling (because it's not used in developing environment).
I could (of course) rename to _styles-IE8.scss and rename it back for production, but isn't there a better way to define which files to compile and which not?

If you are using grunt-contrib-compass, in your Gruntfile.js you can use the specify option to exclude files.
Lets you specify which files you want to compile. Useful if you don't want to compile the whole folder. Globbing supported. Ignores filenames starting with underscore. Paths are relative to the Gruntfile.
ex:
compass: {
options: {
specify: "!/path/to/styles-IE8.scss"
}
}
Then, depending on the environment you can set specify dynamically.

Related

Sass throwing "Error: Can't find stylesheet to import"

Folder structure:
Error description:
Sass version:
ParcelJS solved my problem by being able to compile my Sass/Scss code into plain CSS but i don't want to use it in such a small project like this one.
OS: MX Linux.
Sass is able to compile my code just fine if i don't use #use or #import.
Try importing like below with a relative path:
#use ./abstracts/resets
Here is an overview of how Sass imports files:
Finding the File
It wouldn’t be any fun to write out absolute URLs for every stylesheet you import, so Sass’s algorithm for finding a file to import makes it a little easier. For starters, you don’t have to explicitly write out the extension of the file you want to import; #import "variables" will automatically load variables.scss, variables.sass, or variables.css.
⚠️ Heads up
To ensure that stylesheets work on every operating system, Sass imports files by URL, not by file path. This means you need to use forward slashes, not backslashes, even when you’re on Windows.
Load Paths
All Sass implementations allow users to provide load paths: paths on the filesystem that Sass will look in when resolving imports. For example, if you pass node_modules/susy/sass as a load path, you can use #import "susy" to load node_modules/susy/sass/susy.scss.
Imports will always be resolved relative to the current file first, though. Load paths will only be used if no relative file exists that matches the import. This ensures that you can’t accidentally mess up your relative imports when you add a new library.
💡 Fun fact:
Unlike some other languages, Sass doesn’t require that you use ./ for relative imports. Relative imports are always available.

Are pysa users expected to copy configuration files?

Facebook's Pysa tool looks useful, in the Pysa tutorial exercises they refer to files that are provided in the pyre-check repository using a relative path to include a path outside of the exercise directory.
https://github.com/facebook/pyre-check/blob/master/pysa_tutorial/exercise1/.pyre_configuration
{
"source_directories": ["."],
"taint_models_path": ["."],
"search_path": [
"../../stubs/"
],
"exclude": [
".*/integration_test/.*"
]
}
There are stubs provided for Django in the pyre-check repository which if I know the path where pyre check is installed I can hard-code in my .pyre_configuration and get something working but another developer may install pyre-check differently.
Is there a better way to refer to these provided stubs or should I copy them to the repository I'm working on?
Many projects have a standard development environment, allowing for hard coded paths in the .pyre_configuration file. These will usually point into the venv, or some other standard install location for dependencies.
For projects without a standard development environment, you could trying incorporating pyre init into your setup scripts. pyre init will setup a fresh .pyre_configuration file with paths that correspond to the current install of pyre. For additional configuration you want to add on top of the generated .pyre_configuration file (such as a pointer to local taint models), you can hand write a .pyre_configuration.local, which will act as an overlay and overwrite/add to the content of .pyre_configuration.
Pyre-check looks for the stubs in the directory specified by the typeshed directive in the configuration file.
The easiest way is to move stubs provided for Django in the pyre-check repository to the typeshed directory that is in the pyre-check directory.
For example, if you have installed pyre-check to the ~/.local/lib directory, move the django directory from ~/.local/lib/pyre_check/stubs to ~/.local/lib/pyre_check/typeshed/third_party/2and3/ and make sure your .pyre_configuration file will look like this:
{
"source_directories": ["~/myproject"],
"taint_models_path": "~/myproject/taint",
"typeshed": "~/.local/lib/pyre_check/typeshed"
}
In this case, your Django stubs directory will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django
Pyre-check uses the following algorithm to traverse across the typeshed directory:
If it contains the third_party subdirectory, it uses a legacy method: enters just the two subdirectories: stdlib and third_party and there looks for any subdirectory except those with names starting with 2 but not 2and3, and looks for the modules in those subdirectories like 2and3, e.g. in third_party/2and3/
Otherwise, it enters the subdirectories stubs and stdlib, and looks for modules there, e.g. in stubs/, but not in stubs/2and3/.
That's why specifying multiple paths may be perplexing and confusing, and the easiest way is to setup the typeshed directory to ~/.local/lib/pyre_check/typeshed/ and move django to third_parth/2and3, so it will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django.
Also don't forget to copy the .pysa files that you need to the taint_models_path directory. Don't set it up to the directory of the Pyre-check, create your own new directory and copy only those files that are relevant to you.

Watch a folder, use a specific entry point, then output a single css file

I have a folder of SCSS files. The main SCSS file is /css/app.scss. It imports all the other SCSS files, like /css/variables.scss and /css/component_a.scss.
How can I have sass watch my /css/ folder for any changes, then recompile starting from /css/app.scss?
Right now it errors since /css/component_a.scss uses variables defined in a different file. But in app.scss they are imported in the correct order.
My answer may be limited because I don't have all the information about how you are compiling sass and what settings you are using.
However I can see that your file names aren't prefixed with an underscore, basically sass will compile every file individually that doesn't have the '_' prefix.
Basically what you want to do is set up your task manager (grunt, gulp, etc) to watch all files ending with '.scss' then tell it to run the sass compile task and have this pointed at your app.scss file.
With the limited information I have from your question I hope that my answer points you in the right direction to solve your problem.

force object files in current directory even when subdir-objects is on

I have 2 libraries that share same source files:
# src/lib_mt/Makefile.am:
libppb_la_SOURCES = rphs_mt.c timer_mt.c
# src/sipplib/Makefile.am:
libsipp_a_SOURCES = ../lib_mt/rphs_mt.c ../lib_mt/timer_mt.c
Each source file compiled twice. First for lib_mt with -fPIC, second for sipplib without -fPIC.
Object files for each library created in corresponding directory.
Eventually subdir-objects becomes default. How to keep current behavior for these 2 source files? Some explicit rule maybe?
There is no way to disable that the moment it becomes the default. What you can do instead is migrate this to a non-recursive Automake buildsystem. At that point, it will know that there are different targets compiling the same source files with different flags (it requires AC_PROG_CC_C_O to be called in configure.ac.)
Alternatively, the hacky version is to create a src/sipplib/rphs_mt.c file that only contains
#include "../libmt/rphs_mt.c"
so that it is actually a separate build target.

How to use Sonar Runner on selected files?

I want to run Sonar Runner only on some selected files only. I'm using SonarRunner Ant.
My project directory structure is :
MyProject
|
|-----src
|-----java
|-----A
|-----B
| |---<files>.java
|
|-----C
| |---<files>.java
|
|-----hello.java
Now I want to run Sonar Runner only on hello.java file.
sonar.sources=../../../MyProject/src // takes the source directory
sonar.sources=../../../MyProject/src/java/A/hello.java didn't work
sonar.exclusions=**/**/*.java // excludes all java files
// now I want to include only hello.java file
// didn't find any parameter for inclusion, but tried the following
sonar.inclusions=hello.java // didn't work
sonar.inclusions=java/A/hello.java // didn't work
Referred this article for analysis parameters.
One solution which crossed my mind is : exclusion of all the files but the required ones.
But here the structure is just a small part. In real I have more than 250 java files, and want to generate report for, say, 10 files only. Then, by this approach, excluding 240+ files doesn't look a good idea.
Is there anyway to generate sonar report on selected files, other than the mentioned approach?
If you're looking for specific files, you might try the same syntax as is listed to explicitly exclude files (Narrowing the Focus - at the bottom)
#Absolute Path
To define an absolute path, start the pattern with "file:"
#Exclude all the *.cs files included in /path_to_my_project/myProject/src/generated and its subdirectories
sonar.exclusions=file:/path_to_my_project/myProject/src/generated/**/*.cs
#Exclude all the java classes contained in a src/generated/java directory and its subdirectories
sonar.exclusions=file:**/src/generated/java/**/*.java

Resources