Adding .min suffix when compiling multiple scss file using npm sass - npm

I have many scss files and I'm compiling them to multiple css files using npm sass.
My package.json file is like this:
sass --style=compressed website/assets/scss:website/assets/css
This works fine and saves compressed versions in my website/assets/css/ folder. But I'd like two things to happen.
When saving the compressed version add .min to the file names e.g. style.min.css
Also save a non-compressed file in the same folder (without .min suffix).
How do I adjust my script in the package.json to achieve this?
I'm guessing I need two lines added (one compressed and one not)?
No idea how to do the .min suffix when saving multiple files. Can anyone point me in the right direction?
Thanks

Part two is easy enough to do. Just add another line to the package.json file
"sass": "sass website/assets/scss:website/assets/css"
In the end, I had to use gulp. Everything was achievable easy enough using gulp.

Related

lessc Option --source-map-rootpath seems not to work

I use lessc 2.7.3. I generate css files via a makefile and use following paths
the makefile is in themes/bodensee
the css is generated in themes/bodensee/css
the less files are in themes/bodensee/less
the maps are in the same folder as the css files.
My problem is that css files misses the themes/bodensee path, so it raises a file not found on css.map files.
lessc -s less/wlb.less --clean-css="--s0 --advanced" --source-map-rootpath=themes/bodensee/ --source-map="css/wlb.css.map" css/wlb.css
The CSS file now contains `sourceMappingURL=css/wlb.css.map``The rootpath does not have any effect.
I also tried a fantasy rootpath and searched for it in the file - it does not appear anywhere. But the option is correct. When I try to missspell the option, LESS drops an error.
What am I missing?
Description of the --source-map-rootpath option from here
Specifies a rootpath that should be prepended to each of the less file paths inside the sourcemap and also to the path to the map file specified in your output css.
Because the basepath defaults to the directory of the input less file, the rootpath defaults to the path from the sourcemap output file to the base directory of the input less file.
Use this option if for instance you have a css file generated in the root on your web server but have your source less/css/map files in a different folder. So for the option above you might have
The problem was indeed related to the Clean-CSS plugin.
I now call
lessc --source-map --clean-css="--s0 --advanced" -s less/wlb.less css/wlb.css which is working.
There is a standalone clean-css program, but that does not generate sources for the Less files. It's not clear if the lessc plugin and the standalone tool are the same or different implementations but both use node.
The standalone cleancss tool removes the source map URL generated by lessc be default (did not play around with the dozens of options).
These Node tools develop very fast and manual/tutorials often are outdated. That's why my make file stopped working. Developers of that tools should really consider not to touch working parameters or features and to keep their code compatible.

React-Native: How to open locally bundled binary file

I'm writing a react-native app, and I want it to deploy with a zip file that contains a device firmware update.
Before letting the user send the update, I need my code to open the zip and do some validation of its contents.
I've found lots of zip-handling NPM packages, so all I need to do is load the file contents so I can feed it to one of these.
require('./firmware/fw.zip'); <-- packager doesn't include .zip by default
require('./firmware/fw.pdf'); <-- [gross hack] packager includes pdfs, but the actual result of the require() call is a number: 5. I don't know what I can do with this number to get file contents, but I'm pretty sure this require() system is designed for loading images, not binary data.
ReactNativeFs.openFile('./firmware/fw.zip'); <-- fails with ENOENT
ReactNativeFs.openFile(${ReactNativeFs.MainBundlePath}/firmware/fw.zip); <-- MainBundlePath is undefined on android.
This seems like a really basic question, so I'm sure I've missed a piece of documentation somewhere, but I'm heading into my third hour trying to load the contents of this file with no luck.
I'm pretty sure I could manually put the zip file into the appropriate android and ios resource directories, but that seems like a step down a hard-to-maintain road.
I encountered this problem again a couple months later (I'm apparently the only guy that needs to package .zips in react-native), and the above answer didn't work out for iOS. So I encoded the .zips as base64, put them in .js files, then used import to get the data from those .js files. This actually seems like a somewhat hacky but also flexible long-term solution, without having to mess around with platform-dependent file locations.
See whole answer at my new question: React-native packager configuration - How to include .zip file in bundle?
Partial solution:
Modify android/app/build.gradle, and add
task copyData(type: Copy) {
from '../../firmware/fw.zip'
into 'src/main/assets/raw/firmware'
}
preBuild.dependsOn copyData
This will at least ensure that the file gets copied each time you build, and is then available with ReactNativeFs.readFileAssets('raw/firmware/fw.zip', 'base64'). I'm not entirely thrilled because I still have to have iOS/android dependent code when loading the file, but at least it's loading now.
Tip: watch out for your syntax in gradle. into src/main/assets/myFirmware.zip will create a DIRECTORY called myFirmware.zip, and put your zip file underneath it. Then readFileAssets will still fail because it's finding a directory at your path, not a file.

using npm scripts to Inject *.js and *.css into index.html

I´m looking into switch from gulp/grunt to only use npm scripts.
But I cant really solve how to get *.js and *.css from a given path and add it to the index.html file.
must I add it thru a "index.js" file or can I do something like...
"scripts": {
"inject": "inject src/app/*.js",
},
and then it will add it in my index.html where I have specified it like...
/* inject:js */
The suggestion by Chris Traveis worked out pretty nice.
So the answer to my problem was solved using https://www.npmjs.com/package/postbuild
There were no answers in the last 3 months on this popular topic, probably because there are wrong assumptions in the question. Distilling your question,
...how to get *.js and *.css from a given path and add it to the index.html file
To be short, do it manually. Use a good npm boilerplate such as npm-build-boilerplate and add the compiled JS and CSS files manually into your HTML.
... must I add it thru a "index.js" file, or <2nd option>
No. Add the files manually. Let me elaborate more.
With npm scripts you construct a pipeline and you know where your uglified JS files and compiled SCSS files are rendered. Yes, I have "main": "index.js", row in my package.json, but there's no "index.js" in my project at all. I get npm scripts to crunch files in various folders, to output them into other folders and I manually add end CSS and JS files into HTML templates (in my case, static Hugo website's templates).
I see one case where "dynamism" in the HTML is needed — when you want to bust cache and add the unique strings to the end-point CSS/JS file names. However, then you might want to consider scripts that count MD5 hash of the files' contents, because if you run the build multiple times and your existing CSS or JS files haven't changed, you want to keep the old file names. Visitors might have cached them (and think about CDN too). In this sense, npm postbuild script mentioned in the comments above is inferior because it just uses "version" counter. Look for alternatives to npm postbuild to bust caches.

Generating a single definition file from a external module typescript project

Having a multi file typescript project, using external modules.
If I compile with
tsc -d init.ts -m "commonjs"
Then all the files of the project get their own .d.ts file.
But I would like to generate one single .d.ts file for the whole project.
What's the best way to go about this?
But I would like to generate one single .d.ts file for the whole project. What's the best way to go about this?
At the moment it is handled in a hacky way by : https://github.com/TypeStrong/grunt-dts-bundle
More : https://github.com/Microsoft/TypeScript/issues/1236
You can generate a single d.ts and a .ts and .js bundle using the npm package TsProject.
Have a look at "npm-dts" package. I think it does exactly what you need.
Also, there is a plugin for WebPack called "npm-dts-webpack-plugin".

Are you supposed to put *.css files into git when they're generated from *.scss?

I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.
I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.
In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.
That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.
I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:
Put your source in a src directory, under main/language-name, in this case:
/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss
Then put tests in an identical test directory (you shouldn't need any tests for sass, though:
/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever
Then put your compiled code in a publish-ready directory, like so:
/path-to-my-app/publish/css/my-syntactically-awesome-file.css
Then commit the whole shebang (!)
You can make sure you are always putting your css in the right place like so:
$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/
Now you're a mother effing programmer, baby!