I have installed Bootstrap with Bower in my project
bower install bootstrap
There are several LESS variables that I'd like to override
- less/modals.less (some transition effects)
- less/variables.less (colors)
I don't want to change anything on the bower package so it can be upgraded later.
I'd rather not like to have to redefine an entire Gruntfile for my small modifications.
What do you suggest me to be able to build my bootstrap with Grunt taking my variables keeping the ability to upgrade it with Bower later ?
You can change bootstrap.less. change its #import directives with new .less you want. (Gruntfile.js has reference to variables.less, so I think this option is not what you are looking for).
Or extract (or override) variables you changed from files and to separate .less file(-s) and add new #import to bootstrap.less file.
Related
I'm currently building an npm component library and i'm using a rollup bundling process to compile the library for distribution. The css for the project is written using SCSS, but it also depends on Bulma, which is a css framework written in SASS.
What I would like is to be able to bundle the bulma source code along with my custom scss all into one scss file that I can then use in other projects. That way I can still benefit from the features offered by scss in those projects, such as variables and mixins for example.
I would like this to be automated during the build process so that I don't have to worry about it while developing new components. I've looked at many npm packages for bundling scss files but none of them support SASS and SCSS together. I've also tried converting my project entirely to sass but there doesn't seem to be any good support for sass bundling in general.
So for example, I may have a main.scss file that looks something like this:
#import "~bulma/bulma.sass";
#import "./utils/variables.scss";
It imports both sass and scss files together. This is something that is supported by the sass compiler, and I can compile this to a bundled css file without any issues. But there does not seem to be any support for bundling into one scss file.
The two main NPM packages that i've been attempting to use are:
scss-bundle & bundle-scss
scss-bundle is great, but it doesn't seem to have SASS support, so that's a no-go with Bulma.
As for bundle-scss I converted my project to use SASS and configured the package accordingly, here's the config is used:
{
"dest": "dist/bundle.sass",
"mask": ["src/styles/**/*.sass", "node_modules/bulma/**/*.sass"]
}
From what I can tell, this should go through all of the files in all of the subdirectories of both my styles folder and the Bulma dependency folder and compile them together into one bundle.sass file. And although I would prefer the configuration options from scss-bundle, this is essentially what I am looking for.
However it doesn't work. The package can't seem to resolve the #import statements within the SASS files. Regardless of the syntax I use. And even if it was based on syntax, I can't change Bulma's syntax. Could it be that I'm using the wrong globbing pattern in the mask option? Or does this package just not work?
So my question is, and TLDR:
Can I bundle SASS and SCSS together into one file using some NPM package?
If not, is there a simple and automated way for me to transpile SASS to SCSS and then bundle them together?
If neither of those are possible, is there a working npm SASS bundler that someone can direct me towards? Because bundle-scss does not seem to work.
Also, I am aware that I could just import Bulma separately into the project that needs it, but i'd really prefer to have it all come down together in one package.
Thanks! I hope I explained everything clearly!
I am using VS 2019 for Core 3.1 development and I installed Font Awesome whith Yarn:
yarn add #fortawesome/fontawesome-free
However, whenI try to reference it in my HEAD section like this:
<script defer src="~/lib/#fortawesome/fontawesome-free/js/all.js"></script>
I get the following error:
the 'fortawesome' doesnt exist in actual context
Package managers like yarn, npm, etc. just add the packages to your project. They generally aren't ready to deploy directly at that point, but rather require a build pipeline to create the actual JS/CSS resources. The #fortawesome/fontawesome repo is an exception in that 1) it's not actually a package and 2) the files are already "built". Even then, though, they still won't be in the right location.
I'm not overly familiar with yarn, but npm, for example, puts everything in a node_modules directory. That directory is not served by default, and should not be served, because it contains "raw" stuff. You'd need a separate build pipeline (using npm scripts, webpack, gulp, etc.) to build/copy assets into a directory that is served (i.e. wwwroot). That is likely the piece you are missing.
For this, since there's no build actually required, you just need to have the assets copied to something like wwwroot/lib and then you'll be able to reference it via the script tag on the page. That can be done with any tool like npm, webpack, gulp, grunt, etc. so you'll just have to research and pick the one that fits your needs best.
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
I am new, and when i first created my app based on the documentation using npm create-react-app i found it there were a lot of package included inside folder node_module when i code and i only use react and react DOM and etc from the basic.
node_modules
acorn
timer
ansi
and many more
I wonder if anyone can help my how to understand each use inside the node_module or where can i find the documentation for each use?
or how can i just reduce to what i want to use only to decrease the app size?
The answers are 2:
because you're using an automated scaffolding tool, which essentially does everything for you, and, you have just to code, it is supposed to locally deploy all the packages it needs to work (for example webpack is needed to bundle your code, babel to transpile it, ...
under node_modules you will find all the packages of the whole app. That's means you will find both your dependencies and the dependencies of your dependencies (this rule has some exceptions and you can find them in the npm documentation.
example:
// your code depends on A
var dependency = require('A');
// but then, inside your A dependency you can also find something similar to:
var b = require('B');
how can i just reduce to what i want to use only to decrease the app size?
You basically can't do it. They are all needed.
Most of the libraries that we pull from npm have dependencies. You may use only react and react-dom but there are react-scripts that require lots of stuff. I don't think that you have to worry about the size of the node_modules. That's not what you are suppose to ship in production.
If you want to see what are these all modules about you may open their folder and fine README.md file.
In Sitefinity WebForms you have a ResourceLinks control allowing you to combine multiple, but what do you use in MVC layouts?
I'm not sure if the razor helper #Html.StyleSheet will do the job?
Adding all the CSS files to the Global folder in App_Data\Sitefinity\WebsiteTemplates[template_folder]\App_Themes[theme] will automatically add them to the site, but won't combine them.
We're working with Sitefinity 8.x and looking for a definitive way to compress and combine JS and CSS, but the pickings seem slim.
With the move from webforms to mvc, Sitefinity didn't include specifically introduce a new bundler or something so you're left with essentially 2 default options, but they've seemed to have opted for approach #3.
1) Use .less and .sass to pre-process as part of your build process.
So in your theme folder you would have a global.less (or scss or sass) that essentially combines them using the #import directive.
Install a VisualStudio extension like Mad's Kristensen Bundler and Minification VS Extension (previously part of WebEssentials) and then define in the VS settings that it should compile and minify on build.
Then every time you build or publish, your one bundled-and-compressed .min.css will be available for Sitefinity.
2) Second option would be to use default ASP.NET Web Optimization.
Where you define static bundles in VisualStudio and then use these bundles by means of #Styles.Render or #Scripts.Render to output them.
3) Lastly a new way has been added with the new Feather approach, which uses the current fashionable approach of Grunt to bundle and optimize your styles and scripts.
In the /ResourcePackages folder you'll already see a gruntfile.js file which has a task you can run which can then compile (and can be extended to prefix, bundle, minify, etc) your .sass into a .min.css which you can then add to your solution.
A sample can be seen here (https://github.com/Sitefinity/feather-packages/blob/master/Bootstrap/gruntfile.js)
I'd use a combination of the above approach to receive the maximum result with Sitefinity where you use option 1 to have VS build out your core/base CSS and JS and then include them using Web.Optimization.
Any additional page or widget related styles or JS can then be included afterwards manually through the css widget which gets compiled through option number 3.
Once you get more familiar with this new approach you can create and load optimized .css and .js on demand - even using a RequireJS approach to load them depended on the widget dragged and dropped on the page. RequireJS might seem out-dated given the latest gadgets and gizmo's but with v9.0 its still being used by Sitefinity itself to add inline-editing functionality.
Let me know if you need more info on option 3, I'm happy to extend my answer with some code snippets, or sample scripts on how I've tailored them.