I am working off of a boilerplate WordPress theme built with a gulp workflow. CSS is written using SCSS, I find SASS more intuitive and easier to work with. However when I change the gulp tasks to focus on SASS and not SCSS files I get this error whenever I run the task:
unlock git:(master) ✗ gulp styles
[11:37:25] Using gulpfile ~/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/gulpfile.js
[11:37:25] Starting 'styles'...
[11:37:25] Finished 'styles' after 20 ms
buffer.js:169
throw new TypeError('must start with number, buffer, array or string');
^
TypeError: must start with number, buffer, array or string
at fromObject (buffer.js:169:9)
at new Buffer (buffer.js:62:10)
at Transform.transform [as _transform] (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/index.js:145:21)
at Transform._read (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:184:10)
at Transform._write (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:172:12)
at doWrite (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:237:10)
at writeOrBuffer (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:227:5)
at Transform.Writable.write (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-combine-media-queries/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:194:11)
at write (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:623:24)
at flow (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:632:7)
at DestroyableTransform.pipeOnReadable (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:664:5)
at emitNone (events.js:67:13)
at DestroyableTransform.emit (events.js:166:7)
at emitReadable_ (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:448:10)
at emitReadable (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:444:5)
at readableAddChunk (/Users/tijaniogunlende/Desktop/unlockafrica/wordpress/wp-content/themes/unlock/node_modules/gulp-filter/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:187:9)
When I change the files back to the SCSS source everything works fine.
I know its something small but haven't been able to figure it out.
Thanks in advance.
I had the same error, but I got it from not having any style sheets. So basically I had no styling, and then it tried to put all that nothing into one file. I fixed mine by just creating a one file and putting some comments in it so that it would at least have some content to work with.
I don't know how helpful this is, but here it is anyway.
Related
For a new project I am bound to keep things webpack-only, and thus need to find a way to efficiently compile our stylesheets. Basically in a very gulh-ish way:
gather all less-files including glob-patterns like src/**/*.less (css order may be arbitrary)
also allow import of css files like, say ../node_modules/vendor/**/*.css or 3rdparty/master.less
(If I have to setup a bogus.js entry point for that, fine...)
And with all of that, a typical gulp workflow:
transpile less to css
merge (concat) less and css
have cssnano do its optimization job, with specific css nano options like e.g. orderedValues: false, normalizeWhitespace: true ...
write styles.css as final output
And of course:
have source-maps survive that chain for a styles.css.map
efficient watching and the usual lazy/incremental compilation (as gulp and webpack have it)
Something I do not need is css modules (css imported into node modules for 'scoped' use, coming out as hash-scoped selectors...)
How can a 'typical' less|css-processing toolchain be done in Webpack?
This SO question has my first attempt where I got stuck in config hell right in the middle after combining...
considerations so far (helpful or not)
I know, to webpack, any ressource including css or even font and images is a "module"... Rather than merging my css 'modules' with with actual js (only to later painstakingly separate them again later again), it might be wiser, to have an entry point cssstub.js in parallel – also known as multi-compiler mode.
But that's really, where my wisdom ends... doing a sequence of $things on a set of files in webpack seems really hard (unless it's a connected javascript module graph). I did find something on globbing, but that's not enough (merge css, cssnano,...) and mostly I simply can't glue the pieces together...
I have used gulp to build less and create corresponding maps like below:
First step compiles less and generated css in tmp folder
gulp.task('compile-less', function () {
gulp.src('./*.less') // path to your file
.pipe(less().on('error', function(err) {
console.log(err);
}))
.pipe(gulp.dest('./tmp/'));
});
Second step minifies generated css and create map files
gulp.task('build-css', ['clean'], function() {
return gulp.src('./tmp/**/*.css')
.pipe(sourcemaps.init())
.pipe(cachebust.resources())
.pipe(sourcemaps.write('./maps'))
.pipe(gulp.dest('./compiled/css'));
});
If you want you can add additional step to conact generated css.
You know, I spend more time just trying to get things set up to work with Angular than I do actually developing with Angular. There must be an easier way... :(
Currently, I am using the aspnetcore-spa template, creating a project with the command "dotnet new angular" - this is version 1.0.3, which adds Angular 4.1.2 to the npm dependencies. This works great to get a project running quickly. But now I want to add PrimeNG to take advantage of their form controls. I have been struggling with this all day, and would love it if anyone could provide some assistance.
Here is what I have done in my current effort (the latest of many, starting fresh each time):
1) Added to the package.json file: "primeng": "4.1.0-rc.2"
2) Added 'primeng/primeng' to the webpack.config.vendor.js file's vendor collection.
3) Added the following to my test module (which is in turn referenced in app.module.shared.ts so I can route to it via my RouterModule):
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
And in the html for the module, in an attempt to use the file uploader control, I have (from their site - https://www.primefaces.org/primeng/#/fileupload):
<p-fileUpload name="myfile[]" url="./upload.php"></p-fileUpload>
4) ran "webpack --config webpack.config.vendor.js" from a command prompt at the root of the project folder, which completed with no errors.
Then I hit F5 to run the project, and I got this error:
Exception: Call to Node module failed with error: Error: Template parse errors:
'p-fileUpload' is not a known element:
1. If 'p-fileUpload' is an Angular component, then verify that it is part of this module.
2. If 'p-fileUpload' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '#NgModule.schemas' of this component to suppress this message. (" type="button" (click)="onclick()" class="ui-button-info" label="Click Me">Click Me</button>-->
So, in an effort to comply, I added a reference to the ngprime module to the app.module.shared.ts file, like this (I don't really know how I should reference the module...):
import { FileUploadModule } from 'primeng/primeng';
But got the same exact error.
What am I missing???
Any help would be most appreciated.
I finally have this working, using the asp-prerender-module to get server-side rendering, and not having to rely on the asp-ng2-prerender-module (see my last comment). The trick, I found, was to reference the FileUploaderModule in the app.module.shared.ts file like this:
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
rather than like this:
import { FileUploadModule } from 'primeng/primeng';
The reason this matters is that the latter method of referencing will load all other components as well (see explanation here: https://www.primefaces.org/primeng/#/setup), and SOME of the PrimeNG components can not be rendered on the server due to DOM-related references (things like "window", which do not exist on the server). See the discussion here for more on this: https://github.com/primefaces/primeng/issues/1341
This change, combined with the other steps listed in my answer and, of course, actually referencing the directive in app.module (thank you #pankaj !) made everything work correctly at last. Only took me about 7 hours to figure it out. :(
I'm working with Adobe Extendscript, which == javascript*, and I'm using the Atom JSHint package in Atom. Extendscript is the scripting framework for Adobe apps like Photoshop and After Effects. Adobe do make an IDE but it's really feeble, so I write with Atom and then switch over to "Extendscript Toolkit" to run my scripts. Anyway…
Adobe lets you use C-style preprocessor directives like #include "myUsefulFunctions.jsx" so that you can keep reusable stuff in libraries like a real programming language.
The problem is that the JSHint linter sees my C-style preprocessor directives at the top of the page, freaks out and gives up. To actually get it to lint my code I have to comment the preprocessor directives out and then remember to uncomment them before I run the code. This means at least 3 or 4 extra keystrokes each time I test, which as you all know is The. Worst. Thing. Ever.
So to save half a dozen keystrokes I've been looking into the settings for JSHint. Nothing I've found so far seems related. Is there any way of globally getting JSHint to ignore lines like #this, or locally in the file to get it to skip a line or two?
*or is it ===? I'm really confused by JS's approach to the truth.
I also tried to figure it out for a long time, until I found the best solution.
Instead of using:
#target aftereffects
You can use:
//#target aftereffects
I didn't found any documentations for the above solution.
I just found it in a script over the net, and I tried it and it worked.
And instead using:
#include "some/path/to/file.jsx"
As mentioned in the JavaScript Tools Guide:
evalFile()
$.evalFile (path[, timeout])
Loads a JavaScript script file from disk, evaluates it, and returns the result of evaluation.
path: The name and location of the file.
timeout: Optional. A number of milliseconds to wait before returning undefined, if the script cannot be evaluated. Default is 10000 milliseconds.
You can use:
$.evalFile("some/path/to/file.jsx");
The diffrence is that #include:
Includes a JavaScript source file from another location.
Inserts the contents of the named file into this file at the location
of this statement.
In jshint you can ignore lines by adding a ignore statement to the line.
#target aftereffects //jshint ignore:line
Or you can ignore whole blocks like this.
// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
/* jshint ignore:end */
(BTW the //#target aftereffects is pretty cool. Thanks for pointing that out)
I changed the JSHint package that I use, and now there's no need for workarounds.
For anyone else developing Extendscript in Atom the linter I recommend is this one: Linter-JSHint. It's a plug-in for the Atom Linter package, so you'll need to install that too.
Then once you've done that use this to ignore a block:
// Code here will be linted with JSHint.
/* jshint ignore:start */
// Code here will be ignored by JSHint.
#includepath "lib"
#include myBrilantLib.jsx
/* jshint ignore:end */
or for a single line:
ignoreThis(); // jshint ignore:line
Until recentlly I was using the rather awkward dotless. I'm restricted to what I can use somewhat because I'm using VS2010, however I came across ServiceStack Bundler which seems to work great... apart from one thing.
My Less files are split using a directory structure - to simplify things, like this:
scaffolding/my-scaffolding.less
utilities/my-utilities.less
ui/my-ui.less
Each directories has many files, particularly with mixins etc.
In order to link them together, I've been using the #import function.
My main less file - main.less contains the following:
#import "utilities/all-utilities.less"
All utilities are listed here as it enables me to plug and play various file-sets. This code previously worked ok.
However I find ServiceStack won't pick up changes unless I reference all the less files individually and directly through the bundle file, which is a bit of a pain.
So, I can't use: main.less and import all sub files.
Instead, I have to use:
utilities/util1.less
utilities/util2.less
utilities/util3.less
and so on.
I'm using the ms build function to compile.
Any ideas?
/* UPDATE */
Tried the recommended answer below without success.
This is what I've tried so far:
Call a single less file that contains all #import declarations;
Does not trigger updates on compile.
Call all less files from bundle file and add #import statements to less files where necessary (note bundler won't compile without these);
Duplicates the #imported code as many times as the #import statement is used - even when (reference) directive is used, resulting in bloated/incorrect code.
You should be able to modify Bundler's bundler.js file to specify additional paths that less should search for when processing #import directives:
function compileLess(lessCss, lessPath, cb) {
var lessDir = path.dirname(lessPath),
fileName = path.basename(lessPath),
options = {
paths: ['.', lessDir], // Specify search paths for #import directives
filename: fileName
};
less.render(lessCss, options, function (err, css) {
if (err) throw err;
cb(css);
});
}
A mistake on my part, but one which wasn't easily spottable, so I'll post the reason for my problems so that others don't spend hours as I did chasing a solution to an unecessary problem.
I was using ServiceStack Bundler - I believe this issue would also have occured on on any solution using npm's less library.
My main issue was that none of my changes were triggered on compile. I use lots of #imports and numerous sub-directories for my less files so my first thoughts were the problem was due to subdirectories, and later, due to #import statements. However neither was correct.
I defined a bundle: main.css.bundle
Within the bundle I called my main less file that contained all the other #imported files: main.less
The issue was that less would normally reserve main.css, but the bundle also gives its output the same name based on the bundle name. So both were conflicting.
Change the bundle name or the main less file name and all should work.
I'm trying to take advantage of Google Closure Compiler minification by writing a database script of my own and compiling it with the pre-compiled ydn. To get a basic first version working I'm trying to rewrite the todo list demo from the project. Unfortunately, I don't understand how to keep namespaces for ydn functions preserved in the compiled output file.
Here's what I've written so far: http://pastebin.com/6YhnRuD5
When the code compiles in advanced mode, the "ydn.db.Storage" from "db = new ydn.db.Storage(dbName, Schema)" gets munged into "ydn.db.c$" making it unusable. The goog.exportSymbol at the bottom of the file doesn't seem to save the function names either.
Does anyone know how to rewrite this with Google Closure Compiler? Should this be compiled directly with the ydn source code instead?
The goog.exportSymbol at the bottom of the file doesn't seem to save the function names either.
It should.
goog.exportSymbol("ydn.db.Storage");
should be
goog.exportSymbol('ydn.db.Storage', ydn.db.Storage);