I'm trying to get my head around this sass importer:
https://github.com/idcware/node-sass-jspm-importer
I'm not entirely certain I'm trying to use it correctly.
I'm trying to use the example of using it to import font-awesome.
The GitHub page provides the following example
gulp.task('build-sass', function() {
return gulp.src('src/sass/*.scss')
.pipe(sass({
errLogToConsole: true,
functions: sassJspm.resolve_function('/lib/'),
importer: sassJspm.importer
}))
.pipe(gulp.dest('dist/css'));
});
In this example I'm uncertain how much of a bearing this section has:
gulp.src('src/sass/*.scss')
How does this path make any sense when the SASS/SCSS files are to be imported from JSPM Packages which would have paths like:
jspm_packages/npm/font-aweesome#4.6.3/scss
The lib folder in this section
functions: sassJspm.resolve_function('/lib/'),
Should that be /jspm_packages/ since in the documentation it specifies
Where /lib/ is the path to your jspm_packages folder in your document
root.
In which case why did they not just specify jspm_packages?
I was thinking about this all wrong. One of the things I was missing was that with SASS/SCSS you can use import directives. As such rather than import many generated css files it makes more sense to have the SASS compiler/importer produce one single CSS File.
So I created a single SCSS file that was outside of my JSPM_Packages folder in src called SCSS.
In this SCSS file I could then place the following code
$fa-font-path: jspm_resolve("font-awesome/fonts/");
#import "jspm:font-awesome/scss/font-awesome";
The line in the gulp file:
gulp.src('src/scss/*.scss')
Can then find this single SCSS File and from there work out how to import all the SCSS Files for Font-Awesome through the JSPM_Package folder structure. A single main CSS file was then placed in the destination directory which contained the css from font-awesome.
Which in my case where I'm using ASP.NET Core looks like this:
.pipe(gulp.dest('./wwwroot/css'));
The functions line needed to be set to jspm_packages
functions: sassJspm.resolve_function('/jspm_packages/'),
I'm not sure why they have it as lib in their documentation - maybe this was an old JSPM configuration?
Related
I've created a React project with create-react-app command, it uses webpack.
In order to use SASS I needed to eject with npm run eject command and to manually add SCSS loader inside loaders array, as explained here.
This is my first time with React and I'm using a per comonent style approach which consist in importing a .scss file per component.
I have a global variables file in ~/my-project-folder/src/assets/styles/_variables.scss and I want to import it from ~/my-project-folder/src/scenes/Auth/Login/styles/login.scss, of course I don't want to do something like #import '../../../assets/styles/_variables.scss'.
I've seen that I can refer to SASS files inside node_modules folder this way: #import "~bootstrap-sass/assets/stylesheets/bootstrap/variables"; so I'm wondering what is the way to refer to my project's root directory, i.e. ~/my-project-folder.
When you do this #import "~bootstrap-sass/assets/stylesheets/bootstrap/variables"; it will look for the bootstrap-sass in node_modules but when you want to import your global sass file in your other files then you have to give the relative path otherwise webpack will not able to resolve it for your. You can try to give public path in your webpack
Ive just published my first package (a react component) to npm but im having some trouble understanding the difference between what the lib directory is compared to the dist.
Currently I generate both lib and dist however my package "main" points to the dist unminified js file which has been built using webpack and output as UMD. The lib folder is built using babel taking the src and outputting to lib.
The dist folder contains both [unminified/minified].js files as well as [unminified/minified].css files.
My main confusion is with the lib folder since imports from there currently wouldn't work seeing as I just transform src -> lib meaning the scss references are still there and the scss files aren't transformed either.
I use CSS Modules (css-loader, styles-loader, postcss-loader etc) to generate my CSS files and this is where the confusion is since, wouldn't I also need to use webpack to generate my lib folder seeing as the scss files/import references need to be transformed to css?
Are you meant to have both lib and dist or is the UMD build in dist fulling the same purpose as that of having a lib folder?
If you are supposed to have both how would I achieve this, since I couldnt find any info regarding generating the lib folder when using CSS modules within your js files and still maintaing the same folder structure of that of src (while still generating dist)?
Usually the dist folder is for shipping a UMD that a user can use if they aren't using package management. The lib folder is what package.json main points to, and users that install your package using npm will consume that directly. The only use of the lib as opposed to src is to transform your source using babel and webpack to be more generally compatible, since most build processes don't run babel transforms on packages in node_modules.
As far as handling the style imports, it's probably a good idea to not import scss or css files in your source js that you export. This is because node can't import styles like that by default. If you have an example that demos your component, it makes sense to import the styles there. The common pattern is to publish minified and unminified css in the dist folder, and in your documentation tell the consumer to explicitly import the css file using whatever technique they prefer. I took this approach with redux bug reporter if you need an example. Hope that helps!
In general lib refers to libraries that are included in a package, dist on the other hand are distribution files for your project. As an example you could write a bunch of javascript and include jquery (which is a lib) and then when they're all bundled up you have a single dist file.
Ok think I found out how to do this. There is a babel plugin that allows you to use webpack loaders when running babel (babel-plugin-webpack-loaders). Thus my CSS mapping is inlined within the js file and the mapping hashes used are also the same as that used when building dist. Yay!
I am trying to figure out how I can accomplish the following using brunch. This is the current directory structure for our app:
--app
--base (theme folder, considered the master for all themes)
--sass
--js
--theme2
--sass
--js
--theme3
--sass
--js
...so on
The base folder serves as a master for all other themes. However, if another theme has a file in the sass directory or js directory that matches one in the base folder it overrides that file in the base folder (this applies for imports as well).
I have so far created this which works the way it needs to but it circumvents the brunch pipeline in that I write out the files (doesn't currently support file concatenation) and I would prefer to do this using the proper brunch pipline.
What happens is that each sass or js file it encounters in the base folder is used to generate a new file for another theme. E.g say the base theme has a file called main.scss. The path passed to compile is base/scss/main.scss. Now I want to use this same file for the other themes so I get all the theme folders and dynamically use this base main.scss file for each of the other themes. However, I also alter the inner imports to substitute files imports if they exist in the other themes directory. Its not the same file being spat into multiple locations.
The problem is that I want to dynamically generate new CSS files for brunch to render to different folders not related to the original path passed in (and thus the joinTo config option for this path). By calling the callback, it automatically uses the original path parameter passed to the compile method.
Use overrides in your brunch-config to change your joinTos to include base plus the given theme. You can also customize the build output directory or anything else for each theme if that helps. Then run each build separately using a command like brunch build --env theme1.
After upgrade to Play 2.3, requirejs is able to bundle and unglify all paths into the one main file ONLY if the path's come from a webjar.
Ie. if the config section of my require loos like this
paths: {
bacon: '../lib/baconjs/Bacon.min', // comes from "org.webjars" % "baconjs" % "0.7.2"
'bacon.model': 'libs/bacon.model-0.1.6'
Then Bacon.min.js is correctly bundled into my main.js file but the bacon.model library is downloaded separately via a http call.
I have a bunch of javascript depedencies that are not yet "webjared" so I am trying to find and easy way around this instead of making webjars of all dependancies not provided by webjars.org
instead of requireing code relatively, ie starting with ./ or .., i'd like to define a module "globally". For example, take the following package structure:
/src
/index.js
/a.js
/b.js
/lib
/index.js
...
When in src/a.js or src/b.js, to require lib, I would have to do require('../lib') each time. This gets annoying when you start nesting more as you would have to manually resolve ../lib or ../../lib or ../../../lib.
I want to be able to do require('lib'). Can I do this? Or should I just use globals?
Using a non relative path to require your source files is not how node's require is intended to work! Don't try to work around this restriction by placing arbitrary code file in node_modules directory or workaround by changing the NODE_PATH environment variable.
If you want to use require without a path you should extract the required code as a node module and depend on this node module. This leads to better structured code, less complex modules, encapsulated functionality, better testability and easier code reuse.
You can include package dependencies from http or git so there is no requirement to publish node modules you use in npm. Take a look at npm dependencies for more detail.
use module.exports in the index.js file . and place it inside the node_modules folder
if relative path annoy you and you want to use lib always in your application, you can use global variable like this.
var lib = require('./lib');
global.lib = lib;
you can set lib to global variable in your entry point. after then you can access just lib.
but it's pollute global scope. so you have to use carefully.
placing your module in node_modules dont require you to include a path or relative path
EDIT:
if you place a file named package.json inside the module directory, Node will try to parse that file and look for and use the main attribute as a relative path for the entry point. For instance, if your
./myModuleDir/package.json
file looks something like the following, Node will try to load the file with the path
./myModuleDir/lib/myModule.js
:
{
"name" : "myModule",
"main" : "./lib/myModule.js"
}
If that folder does not contain a package definition file named package.json, the package entry point will assume the default value of index.js, and Node will look, in this case, for a file under the path ./myModuleDir/index.js.