In a project I'm using Bootstrap 5, importing modules from node_modules with a big list of #import (ex. #import "../node_modules/boostrap/scss/functions" etc...).
I'm worried about the deprecation of #import coming soon.
Simply replacing the #import with #use will break the sass build (my compiler doesn't seem to be the culprit as simple cases with #use do work).
It seems to be a problem with the new scoping of #use and npm bootstrap 5.
What should I do?
I've got a running Vue app created with Vue CLI 4 and also installed Tailwind CSS with the help of this tutorial. Since I want to put my custom components into single files and write them in SCSS, my tailwind config file looks like
// tailwind.scss
#tailwind base;
#tailwind components;
#import '#/assets/scss/components/button.scss';
#tailwind utilities;
While serving the app with vue-cli-service serve or building it with vue-cli-service build works great, I am missing the autocompletion feature of my IntelliJ IDEA for all the tailwind classes so that I don't have to use (even tough great) cheat sheets like this.
My idea is to introduce a npm script that will build the full tailwind.css, so that the IDE can utilize it when autocompleting css classes. I know that I can manually build such file with npx tailwindcss build tailwind.scss -o tailwind.css.
However, although that gives me autocompletion for the built-in tailwind classes, it of course neither compiles the SCSS in my custom components nor does it resolve the #import at all. A solution could be to 1) resolve the #import, 2) compile the SCSS to CSS and 3) use the aforementioned tailwindcss build to finally build the full tailwind.css.
Since I am very inexperienced with Webpack, I wonder if you can give me some hints of how to achieve this. Would you even use Webpack for this task?
Webpack is definitely the way to go here, I use this config all the time. See the Tailwind documentation page for setup documentation with webpack
Don't worry about autocomplete for Tailwind, you will learn those classes in no time plus their docs and search function on there are brilliant, no need for external cheatsheets imho.
If you're using post-cssimport you need to put the #import statement before everything else. Check out https://tailwindcss.com/docs/using-with-preprocessors#build-time-imports
Can I import all .scss files in a sub-directories with node-sass?
I'm guessing it would be something like this?
#import './directory/**/*.scss'
No, there is a request on the Ruby Sass GitHub repository for this functionality, but libsass/node-sass won't implement functionality not in the main language. You may be able to find plugins that do this.
My Swift / iOS9 framework 'viewer_protocol' uses another and external Objective-C framework (CocoaAsyncSocket). I'm using Carthage to build CocoaAsyncSocket. So far everything works fine: In have an example App inside my framework Xcode Project using my framework without any problems.
Now I want to use my Framework in a different Xcode Project - although using Carthage. I include only my Framework as a dependency and Carthage automatically resolves the dependencies to CocoaAsyncSocket. I embedded both frameworks into this new Xcode Project and build my App: Everything works fine here - except one warning I can't rid off:
/Users/John/Repositories/my_project/<module-includes>:1:1:
Umbrella header for module 'my_project' does not include header 'GCDAsyncSocket.h'
This is my framework header:
#import <UIKit/UIKit.h>
//! Project version number for my_project.
FOUNDATION_EXPORT double my_projectVersionNumber;
//! Project version string for my_project.
FOUNDATION_EXPORT const unsigned char my_projectVersionString[];
// In this header, you should import all the public headers of your framework
using statements like #import <my_project/PublicHeader.h>
#import <CocoaAsyncSocket/CocoaAsyncSocket.h>
As you can see CocoaAsyncSocket.h is imported. Furthermore inside my framework the CocoaAsyncSocket.h file is included:
What I am missing here? I'm using several others external frameworks inside my framework, there're no warnings for them - all of these external frameworks are written in Swift - CocoaAsyncSocket is pure Objective-C.
This is my frameworks module.modulemap:
framework module my_project {
umbrella header "my_project.h"
export *
module * { export * }
}
module viewer_protocol.Swift {
header "my_project-Swift.h"
}
Update
I found a solution: Changing the import statement in my framework header from
#import <CocoaAsyncSocket/CocoaAsyncSocket.h>
to
#import "CocoaAsyncSocket/CocoaAsyncSocket.h"
Now Xcode finds the header file and the warning disappears.
I recently ran into same issue. Apparently I had header file set as public in target membership, but it was not exposed in umbrella header. Fixed issue by making header file with project access instead of public.
I had the same issue. Seemed to be related to old build files.
The standard Xcode problem fixer worked for me:
Clean project (Product > Clean Build Folder)
Deleted derived data
Restart Xcode
I had the same issue today
Umbrella header for module 'HockeySDK' does not include header 'BITHockeyBaseViewController.h'
and the solution was
1.build and run project and go-to Report Navigator
2.look at the warning, click to expand details
it will so you the file name where you need to make change
as you can seen in below screen shot
So i just updated my import statement in AppDelegate.m file
New
#import "HockeySDK/HockeySDK.h"
Old
#import <HockeySDK/HockeySDK.h>
and issue gone..
hope this will help someone. who are coming here for solution.
For me the solution was as follows:
1) Each Objective C framework has 1 header file that contains all the:
#import ...
#import ...
#import ...
2) Make sure that this file imports the missing header.
3) Build the project again, it should remove the warning.
Alternatively, you may have exposed files within the Public area of your framework's build phases that should actually be moved back to the Project area.
If you don't want those files to be within your framework's umbrella header so they're publicly accessible, you can revert this.
Goto Framework -> Target -> Build Phases and drag to move the unnecessary header files from Public to Project.
Just for completeness if your header is set to public in :
Build Phases > Headers
You should either
Include the import in your main header as others have mentioned
OR
Move that header to "private" if it doesn't need to be exposed
We got this recently and it was due to corruption in DerivedData. Deleting that folder fixed the problem.
For others :
In my case I already move the headers I want to expose from my framework, from "project" to "public" (Build phases of the framework target)
Then Xcode gave my this warning.
Xcode is telling us that we also need to add #import "name of header in the warning> in the public header file that was created with framework, so the clients (of the framework) will know this header.
So The Fix:
1.go to the framework public header file.(the one what created by xcode when you created the framework) .
2. add #import "the-name-of-the-header-in-the-warning.h"
In my case (Obj-c framework):
Umbrella header for module 'opus' does not include header 'opus_multistream.h'
I needed to change:
#import opus.opus_defines;
into
#import opus;
(I don't have in #import "....h" or #import <....h> for frameworks)
Take a look at this post:
#import vs #import - iOS 7
It goes over the concepts of the new module importing.
I had my own custom framework and after adopting the new method to import objective-c framework
old:
#import <MyFramework/MyFramework.h>
new:
#import MyFramework;
it took care of the warning/
Deleting DerivedData did the trick for me. Try running the below command and see if it works.
rm -rf ~/Library/Developer/Xcode/DerivedData
trying to fix a archive build error led me to this error and post
my solution was real simple but took forever for me to figure out.
when i ran $ pod install it generated a workspace for me in the same dir as my .xcodeproj file.
however i had already created a workspace to use as its parent directory.
so then i simply deleted my old workspace and went with the one that pods created
hope this helps someone!
glhf!
For me the fix was rather simple, commit all your changes and build again. The warning disappeared.
Rails 3.1 introduces a new way of organizing both JS and CSS with the introduction of manifest files. For example, application.js might look like this:
//= require jquery
//= require jquery-ui
//= require jquery_ujs
//= require_tree .
This will grab various bits of Jquery, all of your own JS, concatenate them together and serve it as a single file to clients. Simple enough.
Unfortunately the picture is not so clear to me with SASS. SASS already has concatenation built in using #import.
Should I change all of my partials into full SASS files and then concatenate them using the manifest file or continue using #import? Why?
Sprockets converts all imports to CSS before concatenating, so it can't be used to share mixins and variables across files. I'm guessing this is going to stay that way just because you can import SASS, LESS and CSS files via that method.
So here's how I do it:
If I have ERB to include (mostly for asset_path() calls), I put them in my main file, application.css.scss.erb
If I have vendored CSS I want to include, I require it via Sprockets, e.g. //=require jquerymobile
In that same file, I use the SASS #import command to explicitly load all files. None of the #import'ed files may be .erb though.
load the basic stuff (e.g. reset) and imports with mixins
declare variables
import the specific styles
Here's how my app.css looks at the moment. Don't forget the ";" and the quotes:
// Using SASS import is required for variables and mixins to carry over between files.
#import "reset.css.scss";
#import "mixins.css.scss";
$color_base: #9b2d31;
$color_background: #c64e21;
// Using asset_path is important for browsers to use versioned url for the asset.
// This lets us do aggressive caching.
$logo-url: url(<%= asset_path("logo.png") %>);
#import "application/layout.css.scss";
#import "application/sidebar.css.scss";
#import "application/videos.css.scss";
#import "application/pages.css.scss";
...
Note that I'm still exploring the Rails 3.1 asset pipeline, so your mileage may vary. I'll try to come back & update if I find anything else interesting.
The best way to solve this is to use the native #import directive as explained here: https://github.com/rails/sass-rails#important-note
This question was already answered here : how to use sprockets imports with sass
Hope this helps! :)
The sass-rails gem explicitly states not use the require syntax with SASS files - use SASS's #import statements instead.