According to the documentation:
The root directory (where your .flowconfig lives) is automatically included.
And also:
Ignores are processed AFTER includes. If you include and ignore a file it will be ignored.
So, what if I want to specifically include just one or two directories in my root to be processed, and ignore everything else by default? Is there any way to do this?
You don't mention why you want to ignore everything by default, but I'll assume you mean one of two things:
I only want to type check some files
Flow is designed for this use case. You need to add a /* #flow */ comment to the top of any file you want checked, so files that don't have that comment will not be checked by default.
(FWIW, If you did want to check everything, you can use the --all flag.)
Flow was giving me errors for files that I don't want checked
After the 0.22, Flow no longer parses files unless they start with the #flow comment. This change fixes a longstanding issue where Flow would complain about unsupported syntax in node_modules for example.
Hope this helps!
Just to add to Sam's helpful answer and to directly answer the question, I just wanted to mention that as of Flowtype 0.22.0 this is not possible. The root directory that you run flow from is always included by default, and ignores in the flowconfig are applied after includes, so there is no way to manually ignore everything and then include specific directories. However that's not very important since flow doesn't bother parsing files without the /* #flow */ annotation.
Related
Note: I'm open to other solutions if this is the wrong approach
I want to used https://github.com/twitter/css-flip for rtl support on
my project
The documentation is sparse and seems to make a lot of assumptions. I can successfully run the CLI against a .css file but not a scss file as I suspected.
I was thinking about adding a step that ran the css-flip on the compiled styles like so:
css-flip app/assets/stylesheets/application.css > app/assets/stylesheets/application.rtl.css
One, I'm not sure this is the best approach, and Two, if it is reasonable, how could I run the css-flip command on the assets after they've been compiled?
I'm not sure if this is the right approach, but I'd say you can use css-flip to generate your css files, and afterwards, I see 2 different solutions. (In the case you don't want to use Pete suggestion about the direction property, but I assume you may want some custom style depending of the orientation of the language.)
1 - depending on the version of your site, you change the asset being loaded.
2 - Or, I'd say you concat your two css files generated to put both behind a class (probably with the help of a preprocessor such as sass), and you put this class on your body, and change it whenever the user changes their language settings.
solution 1 creates lighter css file, but your user need to reload the page when they change language, whereas solution 2 creates bigger css file, but user won't need to reload their page when they change language.
Hope this helps.
In the official examples they always have /* #flow */ at the top of the page. Now that's nice and helpful for an existing project, where I want to opt-in to flow for each file. Building a new project from scratch I would like to just have flow type checking everywhere, without having to type /* #flow */ every time. Is it possible?
Assuming you have a .flowconfig or you can make one, you can add
[options]
all=true
in there.
Note that this is literally all files, so that will also include random files in node_modules. Another alternative would be to use #flow and just use a lint rule like require-valid-file-annotation for ESLint.
When starting a new project it is always the question which tools, frameworks and libraries to use. I often included the Eric Meyer CSS Reset, but this time I will switch to Normalize.css. I understand it as a customisable starting point rather than a library. I suggest to include the normalize.css file and overwrite specific parts of it. But i am not really sure, if this is the correct way. It would be hard to update the normalize.css file than. It seems Normalize.css is not sure either.
From the documentation at github.com
Normalize.css is a customisable CSS file that […]
README.md, Line 3
It is recommended that you include the normalize.css file as untouched library code.
README.md, Line 21
What would you suggest?
I am guessing this will get closed as it is a question open for debate. However, I would still like to add something to the discussion.
As normalize.css (or any reset css file that I know of) is distributed as a plugin package file, there should be no fault in altering it to your needs. It can be compared to the search for the right break-points for media queries. The truth is, there is no one-way street to follow, it's a delta: every one has to adapt to their project. This also means every developer has to write project specific code. One project might need the first breakpoint to be at 480 px, whereas another project doesn't take mobile devices into account any way, but it does provide very high-resolution displays. Every project is unique, and your code should reflect that.
That being said, exceptions can be made. Libraries, plugins and particular snippets can be used over and over again without any modification. In the case of libraries and plugins, there is some freedom in use per project by means of arguments passed to call to the library or function. For instance, when using jQuery, I will not always write the same code in my scripts file, of course not. That's because a library is only a means to an end, and not a stand-alone package that provides functionality in itself. A plugin (in the wide context) such as, for instance, Modernizr, is another beast all together.(1) The question then arises, what is a CSS reset in this respect? Most will say it's a plugin, and I agree. But should plugins be edited?
I think they can.
Take for example Wordpress plugins. Loads of topics are to be found on the internet concerned this discussion: should they be edited or not. Many peeps advise against it. I don't, and never will. For the simple blogger that wants to add functionality to his or her blog, a plugin in itself should suffice. But we, as web developers, might want more options (or less, to optimise the experience or speed). As long as the dev in question takes updates into account, altering a plugin has no consequence. Why should it?
The same goes for a CSS reset. As I said before, every project has (a) specific stylesheet(s), often one overwriting values in the other. But what good have you on a rule such as this:
/* normalize.css */
h1 {
font-size: 2em;
margin: 0.67em 0;
}
which you then overwrite by your own rules:
/* your-stylesheet.css */
h1 {
font-size: 1.8em;
margin: 0 0 0.8em;
line-height: 1.24;
}
This is ridiculous, doesn't it seem so? I would then advise to edit normalize.css.
However...
Everything I have written down so far (quite a lot, I admit) considers a single project. But what if you often build your own websites, or if you have many sub-sites to a main site and so on? And how should you organise your workspace (directory structure in this case) accordingly?
In the case of sub-sites (for instance websites or projects running on a sub-domain which use the same ftp source but that use a different styling guide) I would advise to use the unaltered normalizer. By doing so, every project has to be modified by rules that have been defined in normalize.css but it keeps you from having duplicate (yet different! for you have edited them per project) normalize.css files spread across your ftp server. Your folder structure would then look like this
- root
-- /index.html
-- /css
--- /normalize.css
-- /project-name-1/
--- /index.html
--- /css
---- /style.css
-- /project-name-2/
--- /index.html
--- /css
---- /style.css
-- /project-name-3/
--- /index.html
--- /css
---- /style.css
This means that index.html in the root shares the same reset (normalize.css, un-edited) as all the (sub-)projects.
To summarise: in an individual project that stands completely alone I'd edit the normalize file and simply see it as a base file to get started with. It's a good guideline, but some things just don't fit a project's needs (for example the heading declaration I mentioned earlier). I myself SCSS-ified and edited normalize.css to fit my needs, and use that as a base file for all my websites. Just keep one copy of it somewhere, and when you get a new project: copy it, edit it, and use it.
1: I am aware that not everyone would agree with me on this distinction. It is based on DOM manipulation: jQuery, for instance, allows functionality, i.e. the possibility to execute functions. You cannot call jQuery which would then trigger an action or manipulation. The basic function of Modernizr, for example, is different. When called, it executes functions and checks functionality of the browser (and adds classes to the DOM).
I decided to use Normalize.css and Reset.css to write my own defaults.
I don't think it's necessary to customize Normalize besides the default font-family, font-size, line-height and some other optional things.
I created Initialize.css, a collection of best practices like normalize and made it configurable with SASS (scss) (there is a css version as well). In this case, you could use normalize and set you own default font-familty, font-size and line-height and if you need some margins to elements like paragraphs and headings. You don't start with CSS overwrites, and that's awesome! :-)
http://jeroenoomsnl.github.io/initialize-css/
IE 8 and lower has a limit to the number of selectors allowed in a single style sheet and once the limit is reached the style sheet needs to be split. Apparently someone addressed this in Compass by creating a way to have Compass do this automatically, and created a gist about it. I however don't have the skills to know what the next step is and there is little in the way of documentation on what to do with this code. Can anyone help with how to integrate this into my Compass install?
Ref: https://gist.github.com/1131536
Thanks much!
Create css_spliter.rb file (as described in your Ref) beside your config.rb file, at the root of your sass project.
Add the following line at the beginning of your config.rb file
require 'css_splitter'
And add the 3 following lines at the end (of config.rb)
on_stylesheet_saved do |path|
CssSplitter.split(path) unless path[/\d+$/]
end
Then run compass compile as you usually do. You won't see the files *myFile_2.css*, *myFile_3.css*, ... appear in the logs but they are well created in your css folder. Also the command compass clean won't remove them, you'll have to dele them manually from your css/ folder.
For what it's worth, there is a Node.js app called Bless that will provide you this functionality. It can run server side or on your local machine.
If you happen to be using CodeKit to compile your Sass/Compass files, it's baked in, you just have to enable it in project settings.
I think the css_splitter solution forgets to remove the code from the first file. Now I have 2 files, the first one is all of my css and the second generated file has the 2nd half of the original file. So I have 150% the amount of CSS as I used to... I did fix my problem in IE though :)
in direct regards to my last question.
my css files are located in the app_themes directory.
so im not the one adding the reference to them in the master page.
so how can i implement the solution they gave me in my last question?
thank you!
CSS Files in the app_themes directory has been a thorn in my side as well for this reason, and also because of not being able to control the load order.
I am not sure how to access them programmatically, at least not as objects.
The load order is alphabetical, so I have in the past just put a number in front of all of the style sheets to indicate load order, like I would name the files 1_Stylesheet.css, 2_Stylesheet.css, and so on.
You could do the same thing, and just build the version number into the file name to force the cache to get the new files, so each time you have a new version you just rename the file 1_Stylesheet_v1.css, 1_Stylesheet_v2.css and so on. Since they are added automatically changing the names themselves should not break anything.
This is not the ideal solution, I would love to see a better one, that is not overly complicated.