I've been working on a way to speed up my workflow with SublimeText2 and Sass.
I was looking for a way to have ST2 compile my SASS when I save. In looking how to do this, I came across this package: https://github.com/bnlucas/SassBuilder
In execution, it is exactly what I wanted, but it does not compile SASS like I hoped (doesn't include partials support).
So after more research I found a build package that works for me:
{
"cmd": ["sass --watch 'index.scss':'index.css'", "--stop-on-error", "--no-cache"],
"line_regex": "Line ([0-9]+):",
"osx":
{
"path": "/usr/local/bin:$PATH"
},
"windows":
{
"shell": "true"
}
}
This is similar to running the following command in a cmd prompt with Ruby:
sass --watch index.scss:index.css --stop-on-error --no-cache
So I run this build system and it watches my index.scss just fine. Any changes made to any of the .scss files in that folder and it updates the .index.css file. All of the standard messages from Sass are displayed in ST's console.
My issue is I know that is not what ST's build systems are for. Ideally, they would be used to build with a set of tools multiple times in a coding session.
My question is: How can I use ST2 to launch a sass --watch and have it run in the background? Is there some sort of command/key binding I could set to run the build's cmd line ("cmd": ["sass --watch 'index.scss':'index.css'", "--stop-on-error", "--no-cache"])?
Check out the SublimeOnSaveBuild plugin, available through Package Control. Since you already have a working build system, all you need to do is configure the plugin to point to your .sublime-build file, modify the file endings if you want, and you should be all set.
Good luck!
Related
I'm trying to get sass to run through the terminal and when I try, I get the error mentioned above. It seems that the installation of sass itself was successful because I can see it in my package.json file:
"devDependencies": {
"sass": "^1.51.0"
}
I have tried uninstalling/reinstalling sass, and restarting the client, but can't get the 'sass' keyword to work. I currently have my project located in a folder that github is also directed at so I can make pushing updates to github easier. Any help would be greatly appreciated.
Try npx sass, or create a new entry in the scripts section of your {package,yarn}.json file that calls sass.
"scripts": {
"build": "sass input.scss output.css",
}
Then, npm run build or yarn build, depending on which package manager you are using.
https://sass-lang.com/documentation/cli/dart-sass
Could you please give me some advise on how to deal with this issue.
Build Pipeline
npm install
package.json
"dependencies": {
"cypress": "^3.4.1"
}
Release
Powershell command
npm ./node_modules/.bin/Cypress run
The cypress npm package is installed, but the Cypress binary is missing.
2019-10-07T18:04:59.5720120Z We expected the binary to be installed here:
There are some examples on how to cache ~/.npm but nothing seems to work so far. Examples on how to include cypress.io in your vsts are at the building stage and not after release.
According to the error log, it has provided a solution about this. You should run the cypress install command first and then the error will be fixed.
As my test, since I don't have a cypress.json file, so I need run the open command to
automatic generated get the json file and project sample.
Then the open command run as expected.
But because I run the open command in interactive mode and I don't have the cypress.json file in my artifacts, the taks finally failed.
So if you have cypress.json in your repo or artifacts, you just need to add
.\cypress install
in your powershell command.
And if not, you can add the related json file and folder to your repo or artifacts and then the run command will work as your expected.
Can anyone please help explain this? I am new at using Sass. But I cant understand why people use compiler for sass files when they can be run through terminal.
I actually had the same question some time ago when I was learning SASS.
I kept wondering why most tutorials involved using GRUNT / GULP or some kind of task runner when there where sass proprietary commands even for live-watching your files with a command such as:
sass --watch app/sass:public/stylesheets
I will quote myself here in the question (that no one answered) just to share my experience with SASS compiling:
Grunt: using grunt-contrib-sass - Everything has worked smoothly; I chose this one over grunt-sass for no particular reason, but I've read that the latter uses libsass(c++) which is faster than the traditional ruby Sass.
Gulp: using gulp:sass - I often encounter an error when watching
files, it doesn´t find some partials, but if you save again,
everything is fine (this is addressed in their common issues -this
solution hasn't worked for me though), also it doesn't generate sass
maps as a default you have to use gulp-sourcemaps on top.
Straight from Console: no task runners - Works fine so far, generates
sourcemaps, and lets you know where there's an error, just like with
Grunt and Gulp.
So after working on different projects using SASS I'd say the reasons are:
Tutorials popularized the use of task runners when using SASS in its early times
In a project, you rarely use SASS just by itself, you most likely want to run other tasks, so it makes sense to add your SASS task to the flow, which saves time and makes sense.
It's easier to run a simple command such as gulp sass or just gulp to run the default gulp task (that should include the sass task) than to remember a long command in which you have to put the paths over and over again.
After a while I realized that you can use NPM scripts in your package.json to run the SASS command line tools like so:
"scripts": {
"sass": "sass --watch app/sass:public/stylesheets --style compressed"
},
And then run it from the command line: npm run sass
the above requires no configuration and you don't have to remember the whole command by heart.
To conclude, there is nothing wrong in using the CMD SASS without other compilers/task runners, just use whatever you feel most comfortable with.
I've been trying to use sass in sublime text 3 today and for that I installed Ruby, Ruby SASS gem and the Sublime packages Sass and Sass Build. All seems to be working well but when I try to build the css file (using the Sass Build package) I get this weird error:
[Decode error - output not utf-8]
[Finished in 0.1s with exit code 1]
[cmd: ['sass', '--update', 'F:\\Program Files (x86)\\wamp\\www\\singlepage\\wp-content\\themes\\manaca\\style.scss:F:\\Program Files (x86)\\wamp\\www\\singlepage\\wp-content\\themes\\manaca/style.css', '--stop-on-error', '--no-cache', '--style', 'compressed']]
[dir: F:\Program Files (x86)\wamp\www\singlepage\wp-content\themes\manaca]
[path: C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;F:\Program Files (x86)\MacType;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files (x86)\Autodesk\Backburner\]
And when I try to build the compressed CSS (from the same package) it simply returns
[Decode error - output not utf-8]
[Finished in 0.1s]
What's been bugging me is the crazy file paths returned in the last line (shouldn't even be searching in C: )
The other thing I've been researching about is the output not utf-8 thing. Even if I specify the charset on my sass (or scss) file, the problem lingers.
Anyway, I appreciate any type of help I can get.
"shell": true - this is the key.
If I try build-system like this (on WinXP):
{
"cmd": ["ant", "-f", "project-build.xml"],
"working_dir": "${project_path}"
}
I get:
[Decode error - output not utf-8]
because cmd should be "ant.bat" instead.
Sublime is looking for file exacly called ant and encoding of "file does not exist" message is not utf-8.
When I use shell like this:
{
"cmd": ["ant", "-f", "project-build.xml"],
"working_dir": "${project_path}",
"shell": true
}
everything works fine (even without "windows": { "cmd": ....} ) because shell searches for ant.exe and then ant.bat.
I've worked around the problem.
The path thing was a missing step of my Ruby installation on Windows. I needed to register Ruby's path in Environment Variables.
But still the package Sass Build wasn't working so I opened cmd and told Sass to watch the file, inside my website folder:
cd "program files (x86)\..\mysite"
sass --watch style.scss:style.css --style compact --no-cache
Now every time I save the style.scss file the css file is updated properly.
Hope that clarifies the process to anyone else!
Just a reference for people who had similar problem and the accepted answer didn't help:
I had a similar error, in my case I had to install python and add it to the PATH environment variable.
add ruby to envirement variable PATH.
I've got this error when I open Sublime Text from a console window. Open Sublime from a normal shortcut.
Just in case someone else comes across this on a different matter, I was building a project in openCL (using C API not C++) and encountered this error.
Turns out I hadn't allocated enough memory for the string to hold the program build log.
I have developed a node.js npm module, developing under Windows. Today I wrote some Mocha tests. After many struggles, it seemed that for npm test to work, package.json had to look like this: (there may be other options???)
"scripts": { "test": "node node_modules/mocha/bin/mocha" }
instead of what's in all the Unix based books,
"scripts": { "test": "./node_modules/.bin/mocha" }
How can I set package.json up to work on both Windows and Unix? I'm assuming that Travis-CI runs Unix, so, should I link the build to that, it will blow up with the Windows version.
I found a two year old thread where somebody requested a feature for exactly this. That thread seemed to die out. This SO question seems to be close, but it isn't exactly what I want and, frankly, I can't understand the answer. :-( Can anybody clarify?
For the time being, I am going
"scripts": {
"test": "node node_modules/mocha/bin/mocha",
"testOnUnixUseThis" : "./node_modules/.bin/mocha (I think)",
"testOnWindowsUseThis" : "node node_modules/mocha/bin/mocha"
},
Unfortunately, you cant go npm test testOnWindowsUseThis or npm testOnWindowsUseThis. And it doesn't fix the Travis-CI issue. But at least a person who downloads the module can (hopefully) see what is going on.
Any better ideas? Am I the only person still developing under Windows??? :-)
I've always been able to npm install -g mocha or npm install mocha and then just add
"scripts": {
"test": "mocha spec"
}
to package.json. That may or may not work in EVERY environment. I know, for instance, with lineman, you have to use bin/mocha. Also, if you don't find a way around this, set your test script up for Unix and then add a second script called "wintest" or something that does whatever you need it to do in Windows. You can name your scripts whatever you want. The default ones (test, start, etc.) can be used with npm [command]; any non-standard ones (like wintest) can be used with npm run-script [command], and they will still work.
A little back story on how/why this works:
When you install a module globally, it's available on PATH (or whatever the windows equivalent is). When you install a project dependency, if that module has any binaries, those are symlinked to node_modules/.bin and when you run npm run [some-command], npm helpfully adds node_modules/.bin to PATH for that command. So when mocha is installed globally "test": "mocha spec" uses your globally installed mocha to run tests. When it's a project dependency, it uses the one in node_modules/.bin. The one gotcha I've found with this is that npm adds node_modules/.bin to the front of PATH, so local binaries will always take precedence over global ones. Almost all of the time, this is what you want, but it's worth knowing that that's how it works (I recently had a bug related to this).
EDIT:
Not sure at what point in npm history this changed, but npm run <script-name> now works (don't need to do npm run-script <script-name> anymore). Possibly run-script still works as well. I'd expect it to, but I haven't tried it.
How can I set package.json up to work on both Windows and Unix?
If you
use Windows
dislike -g global install
...this is a working solution
"scripts": {
"test": "node node_modules/mocha/bin/mocha.js"
},
Notes:
putting node in front shouldn't harm, and can help on Windows (.js extension is not necessarily registered to the nodejus executable, unless you set it so. Could open a text editor, an IDE or (worse) windows scripting host, Internet Explorer…)
Adressing the script directly saves you from needing a global install. (Not judging if this is a good practice)
forward slashes help running under linux (obviously) and do work under windows (in this scenario. Also avoids a windows pitfall: backslashes if used, would need to be doubled – since they are interpreted as escaping the following letter if used solitary).
Don't use global solution, I suggest you follow what the Mocha guys say:
"scripts": {
"test": "node_modules/.bin/mocha -w"
},
Use npm i mocha --save-dev
This will save the module as a development dependency and npm will automatically set up the executables to be used within the scripts object. If you want to use the executables outside of the scripts defined in package.json, you can install it globally as well, although note that you may end up with different versions of the package.
If you only install it globally, other people won't be happy if they try to run your tests (with the standard npm test)
The new way with latest npm versions after 6.x, you needn't install mocha with global mode any more.
"scripts": { "test": "npx mocha" }
npx is installed automatically with new npm installation. It will search
mocha from node_modules/.bin or $PATH
reference: https://www.npmjs.com/package/npx