Currently I use less-middleware (https://www.npmjs.com/package/less-middleware). I am not satisfied with this solution, because less-middlware create a compiled css file. I want a memorized solution I can route via expressjs.
Besides, I want to work with a proper autoprefix solution, because there are many nice css technologies I cant use because I would need to much time to add the vendor prefixes.
Do anybody know a better solution for instant less compilation without outputing a separate css file.
Can this solution offer some kind of autoprefixing functionality?
Does offer less-middleware offer an autoprefixing functionality. I have not found something in that direction.
You should try to reformat your question, because of:
Questions asking us to recommend or find a book, tool, software
library, tutorial or other off-site resource are off-topic for Stack
Overflow as they tend to attract opinionated answers and spam.
Instead, describe the problem and what has been done so far to solve
it.
I found https://github.com/toogle/express-less/blob/master/lib/express-less.js according their package.json file, Express LESS middleware uses the latest version of Node Less.
In their code the call less.render() here: https://github.com/toogle/express-less/blob/master/lib/express-less.js#L68 and more information can be found here: http://lesscss.org/usage/#programmatic-usage
Since version 2 of Less you can use plugins. An autoprefix plugin is available at: https://github.com/less/less-plugin-autoprefix
So you should be able to use the follow code:
var express = require('express'),
expressLess = require('express-less'),
autoprefixer = require('less-plugin-autoprefix');
var app = express();
app.use('/less-css', expressLess(__dirname + '/less', { plugins: [autoprefixer] }));
Also see: http://lesscss.org/usage/#plugins-using-a-plugin-in-code
Notice i did not test the above code. I wondered how to set the autoprefixer option. According to https://github.com/plus3network/gulp-less#using-plugins you should use:
var autoprefixerPlugin = require('less-plugin-autoprefix'),
autoprefixer = new autoprefixerPlugin({options});
var app = express();
app.use('/less-css', expressLess(__dirname + '/less', { plugins: [autoprefixer] }));
According to the documentation of Less Engine, the way to use a plugin is the following:
less.render(myCSS, { plugins: [myPlugin] })
Source: http://lesscss.org/usage/#plugins-using-a-plugin-in-code
Then according to the documentation of Less Middleware, the way to add options into second parameter of render() function is the following:
The options.render is passed directly into the less.render with minimal defaults or changes by the middleware.
Source: https://github.com/emberfeather/less.js-middleware#render-options
So according to the documentation of Less Autoprefixer ande the documentation of Express Engine, the definitive and true way to use it is using this code:
var express = require('express'),
lessMiddleware = require('less-middleware'),
lessPluginAutoprefix = require('less-plugin-autoprefix'),
app = express(),
autoprefixPlugin = new lessPluginAutoprefix({
browsers: ["last 2 versions"]
});
app.use(lessMiddleware(path.join(__dirname, 'public'), {
render: {
plugins: [
autoprefixPlugin
]
}
}));
This was implemented and tested in the NodeAtlas NPM module.
Related
Hi there I have been forced to come here due to every resource out there on the topic is very poor and incomplete.
Not only on the babel site but every single post out there is not complete and informative enough.
I tried to reach out at the babel forum and no replies.
I am trying to convert my prototype libraries to Es6 and convert to the most leanest possible code. So no bloaty duplicated generated code and if possible no bloaty requirejs and whatever browserify generates.
I have tried to make a project with grunt and babel directly, configure the external-helpers plugin according to the babel documentation.
It fails to include the relevant helper code and fails to include the import module code altogether.
ie a babel config like
{
options: {
sourceMap: false,
presets: ['es2015'],
"plugins": ["external-helpers"]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
The main project file has an import like
import Button from './ui/buttons/Button';
The module code looks like this as if the export is placed underneath extra code is generated for that.
export default class ShareButton {}
produces an output like this
Object.defineProperty(exports, "__esModule", {
value: true
});
require('babel-core/external-helpers');
var _Button = require('./ui/buttons/Button');
var _Button2 = babelHelpers.interopRequireDefault(_Button);
No source of the module or the helper object is included.
I searched hard for how to deal with external-helpers and it suggests it has to be imported into a separate file ie something like this to generate only the helper functions needed
babel-external-helpers -l createClass > src/helpers.js
But any resource regards to this fails to go as far as to how to import that into the project.
If I use the transform-runtime plugin, it produces a massive polyfill that cannot be disabled so a bug and not so useful for what I need.
"plugins": [
["transform-runtime", { "polyfill": false, "regenerator": false }]
]
If I use browserify / babelify it makes a royal mess and duplicates code still.
A config like
{
options: {
"transform": [["babelify", {
"presets": ["es2015"],
"plugins": ["external-helpers"],
sourceMap: false
}]]
},
dist: {
files: {
'build/<%= package.name %>.js': ['src/<%= package.name %>.js']
}
}
}
Produces code like this still with the external helper missing and duplicated code not relevant to the helper. ie
Object.defineProperty(exports, "__esModule", {
value: true
});
Is within every module in the generated file.
If I export the classes like this at the bottom of every file
export default class {}
Duplicated code is generated like
var _class = function _class() {
babelHelpers.classCallCheck(this, _class);
};
exports.default = _class;
In terms of filesize that doesn't include bloaty wrapping code like
},{}],2:[function(require,module,exports){
It seems concatting all the prototype classes files together to bundle in one file is the winner still.
So trying to port the library but keep it similar and bundle it together into one file.
Hopefully this is concise enough and there is a simple solution.
FYI browsers do not understand tabs and 4 spaces. I had to edit this post in my editor to get the code blocks working ! It would be nice to have a markup like other places like "```" ?
Let me know thanks.
I'm using rollup with babel now. Rollup produces a clean output as umd mode. Browserify is really bloaty in itself.
There is just a problem with polyfills being converted. I have to concat external ones in like for WeakMap.
I had a problem trying to use the generated Iterator and finding a polyfill for that so I have to code loops a particular way it doesn't generate Iterators.
The polyfill generation in babel is still too bloaty and crazy. It's pretty terrible. So I concat in minified polyfills that are very small and it's used globally.
I was running into something very similar. Was tired of trying to do it the "right way" and ended up just creating https://www.npmjs.com/package/grunt-babel-helpers which simply manipulates the string output.
I am trying to learn about technologies including Grunt, Gulp, Webpack, Browserify, but I did not feel that there is much difference between them.
In other words, I feel Webpack can do everything that a task runner does. But still I got a huge examples where gulp and webpack are used together. What's the reason?
I might be taking things in the wrong direction. Am I missing anything? If so, what?
Grunt and Gulp are actually task runners, and they have differences like config driven tasks versus stream based transformations. Each has its own strengths and weaknesses, but at the end of the day, they pretty much help you create tasks that can be run to solve a larger build problem. Most of the time, they have nothing to do with the actual run-time of the app, but rather they transform or they put files, configs and other things in place so that the run time works as expected. Sometimes they even spawn servers or other processes that you need to run your app.
Webpack and Browserify are package bundlers. Basically, they are designed to run through all of a package's dependencies and concatenate their source into one file that (ideally) can be used in a browser. They are important to modern web development, because we use so many libraries that are designed to run with Node.js and the v8 compiler. Again, there are pros and cons and different reasons some developers prefer one or the other (or sometimes both!). Usually the output bundles of these solutions contain some sort of bootstrapping mechanisms to help you get to the right file or module in a potentially huge bundle.
The blurred line between runners and bundlers might be that bundlers can also do complex transformations or trans-pilations during their run-time, so they can do several things that task runners can do. In fact, between browserify and webpack there's probably around a hundred transformers that you can use to modify your source code. For comparison, there's at least 2000 gulp plugins listed on npm right now. So you can see that there are clear (hopefully... ;)) definitions of what works best for your application.
That being said, you might see a complex project actually using both task-runners and package bundlers at the same time or in tandem. For example at my office, we use gulp to start our project, and webpack is actually run from a specific gulp task that creates the source bundles that we need to run our app in the browser. And because our app is isomorphic, we also bundle some of the server code.
In my humble opinion, you might want to get familiar with all of these technologies because chances are you will see (use) all them in the course of your career.
I've just created my own task runner/bundler.
It's simpler to use than gulp and probably webpack (although I've never used webpack).
It's very simple and has babel, browserify, uglify, minify, and handlebars out of the box.
The syntax looks like this:
const Autumn = require("autumn-wizard");
const w = new Autumn();
//----------------------------------------
// CSS
//----------------------------------------
var cssFiles = [
'./lib/pluginABC/src/css/**/*.{css,scss}',
];
w.forEach(cssFiles, srcPath => {
var dstPath = w.replace('/src/', '/dist/', srcPath);
dstPath = w.replace('.scss', '.css', dstPath);
dstPath = w.replace('.css', '.min.css', dstPath);
w.minify(srcPath, dstPath, {
sourceMap: useSourceMap,
});
});
//----------------------------------------
// BUNDLE THE JS MODULE
//----------------------------------------
var srcPath = "./lib/pluginABC/src/main.js";
var dstPath = "./lib/pluginABC/dist/bundled.min.js";
w.bundle(srcPath, dstPath, {
debug: useSourceMap,
});
//----------------------------------------
// CREATE THE HANDLEBARS TEMPLATES
//----------------------------------------
var tplPaths = [
"./lib/pluginABC/src/templates/**/*.hbs",
];
dstPath = "./lib/pluginABC/dist/templates/bundled.js";
w.precompile(tplPaths, dstPath);
And the doc is here: https://github.com/lingtalfi/Autumn
Hopefully it helps.
I am working on a website with React.js and asp.net mvc 4, I am planning to use Flux as my front-end architecture, but I met some problems and was very confused about the use of Flux:
In the beginning,I thought Flux would be a perfect front-end architecture in my website,but after I read a lot of articles about Flux, I find that they are nearly all with NodeJs,even the demos from facebook team,that means they all do the rendering stuffs of React.js/Flux code in server side,right? but How can I use Flux in the client side ,I mean in the user's browser?
I am very confused,am I wrong if I treat react.js/flux as a client side solution?If I am not wrong, but why they all use them with NodeJs and ES6(like facebook Dispatcher.js), That's ok in server side,but what about client side ? most of user broswers don't support ES6. I tried using Babel to convert Dispatcher.js from ES6 to ES5,but the es5 version had some errors and didn't work.
And I also found some implements of Flux that claim to support client side,like fluxxor,but I don't have a chance to try it before I write this post,because I am too confused.
I hope someone can help me to figure out these problems.
ps. Sorry for my english,if you don't understand my words,pls let me know , I will explain it.
I think you want :
$ bower install flux
Then you could do something like this (if using require.js):
require(
['bower_components/flux/dist/Flux'],
function(
Flux )
{
var dispatcher = new Flux.Dispatcher();
dispatcher.register(function(payload) {
if (payload.actionType='test') {
console.log('i got a ', payload);
}
});
dispatcher.dispatch({
actionType: 'test',
otherData: { foo: 'bar' }
});
});
(This answer uses : https://bower.io/, https://libraries.io/bower/flux, http://requirejs.org/)
React is a client side library. You can serve a React App with virtual any backend language. The reason a lot of examples are with node is because it is easy and fast to set up.
You should try this tutorial:
https://facebook.github.io/react/docs/getting-started.html
It is pretty straight forward and doesn't require node.
Also maybe you should try starting to serve the React app statically at the beginning to better understand React itself.
ES6 works in Browsers thanks to Babel. If you believe you have any trouble with Babel, you might want to first play around with it's REPL to get a feeling for it: https://babeljs.io/repl/
The idea is that the code can run on the client and server (universal js, used to be called isomorphic javascript (though it goes a little further then that with serverside rendering etc..),
There are many flux implementations reflux is the most promising at this point , im using martyjs (but they stopped the development, it will be taken over by alt) but even for the flux architecture, u just get the dispatcher / event emitter and some ideas :D,
Shorty said u can install the npm packages (flux, react , babel) etc, but u need something like http://browserify.org/(with reactify) or Webpack, to run them in the browser. U don't need to run them on a node js "after its bundled", webpack/browserify will bundle the code so it can used within the browser independently
https://github.com/christianalfoni/flux-react-boilerplate/ <-- ther are some boilerplate, that provide some nice guide on how to bundle the code.
I'm trying to use grunt-contrib-livereload, but can't seem to figure it out. The readme seems to skip over everything that I need explained, and then ends with an example that doesn't work when I try it and doesn't seem directly related to the documentation. I have searched for a better explanation in a blog post or tutorial or whatever, but haven't been able to find one. Can someone please explain how to get started with this tool?
Here are the kinds of questions I have, based on the readme:
The documentation says the livereload task "must be passed the list of files that have changed" --- but how do I pass it this list of files? The example does not seem to illustrate this. Does regarde pass the list?
Is grunt-contrib-connect required? What does it do, and how do I use it? Do I need to learn connect before I try using livereload?
The readme mentions middleware that "must be the first one inserted" --- but inserted into what, before what else? And how is it inserted?
And I suppose I don't understand how I need to manipulate ports. "All the browsers listening on the livereload port will be reloaded" --- but how do I know which browser is listening to which port? Do I need to learn all about ports before I can try using livereload? (Any suggestion on how to best learn about that?)
Finally, in the example, there is a folderMount function that doesn't seem related to any of the documentation before. What is that, and do I need it?
I guess I'm asking if someone can please:
point me towards a tutorial that is much more effective than the current readme;
explain these unexplained parts of the readme, if those answers are what I need to understand the plugin;
or provide a functional example with some explanation of why it is functional.
Live reloading is now built into grunt-contrib-watch version 0.4.0. grunt-contrib-livereload and grunt-regarde will be deprecated soon.
Now just set the option livereload to true in your config and it will create a live reload server then reload after the tasks have run:
grunt.initConfig({
watch: {
all: {
options: { livereload: true },
files: ['lib/*.js'],
tasks: ['jshint'],
},
},
});
By default the live reload server will be started on port 35729. So to enable live reloading on your page just add <script src="http://localhost:35729/livereload.js"></script> to your page.
View more info on the docs: https://github.com/gruntjs/grunt-contrib-watch#live-reloading
Edit: Check versioning info. grunt-contrib-watch now has livereload support baked in.
What a doozy. I ran into issues with this one too so let me do what I can to explain (or at least get you up and running). Keep in mind, this is how I have it set up and it seems to work most of the time.
For starters, you'll want to make sure you've udpated your package.json with the right dependencies. I'm not sure that livereload works with the baked in "watch" task and I've been using grunt-regarde of late. My package.json usually looks like this:
"dependencies": {
"grunt": "~0.4.x",
"grunt-contrib-livereload": "0.1.2",
"grunt-contrib-connect": "0.2.0",
"grunt-regarde": "0.1.1"
},
Obvi you want grunt (duhhh), livereload, connect seems to help with mounting folders, and regarde is like grunt-watch, it just seems to work better (I forget why exactly).
You could make your package.json even better by specifying livereload in its own "devDependencies" object if you're so inclined. Now, run your good old fasioned npm install to get the goodies in your project.
Let's talk gruntfiles:
As you probably know, the gruntfile is what makes the magic happen. Somewhere towards the bottom of your gruntfile, you'll want to specify
grunt.loadNpmTasks('grunt-regarde');
grunt.loadNpmTasks('grunt-contrib-livereload');
grunt.loadNpmTasks('grunt-contrib-connect');
At the top of your gruntfile, we'll want to add some utils for livereload. Under /*global module:false*/, go ahead and add var lrSnippet = require('grunt-contrib-livereload/lib/utils').livereloadSnippet;.
After that, you don't really need to learn connect, you just gotta use it. Check my style:
var folderMount = function folderMount(connect, point) {
return connect.static(path.resolve(point));
};
This comes before module.exports = function(grunt) {
Now let's get into the meat of the gruntfile. Again, I forget what connect is doing but this is where the middleware magic comes into play. In your modules.exports, add:
connect: {
livereload: {
options: {
port: 9999,
middleware: function(connect, options) {
return [lrSnippet, folderMount(connect, '.')]
}
}
}
},
Now we want to have the files watched. I like to set up a few different tasks since I don't want my whole grunt process running every time I save a CSS file. Here's what I work with (again, add to module.exports):
regarde: {
txt: {
files: ['styles/*.css', 'index.html'],
tasks: ['livereload']
},
styles: {
files: ['sass/*.scss', 'sass/*/*.scss'],
tasks: ['compass']
},
templates: {
files: ['templates/*.jade'],
tasks: ['jade']
}
},
You can see that I only want livereload to fire when there have been changes to my compiled css (*.css) or to my compiled html. If I edit a SCSS file, I want to fire off just compass. If I edit a jade template, I want to only fire the jade to HTML compiler. I think you can see what's going on. You can toy with this, just be smart about it because you could get caught in an infinite loop.
Lastly, you need to fire off these processes. I like tying them all to my main grunt task because my gruntfile is just that sweet.
// Default task.
grunt.registerTask('default', ['livereload-start', 'connect', 'regarde']);
Now, when you fire up grunt in the CLI, you should (hopefully, maybe, cross your fingers) get something like this:
Running "connect:livereload" (connect) task
Starting connect web server on localhost:9999.
Browse to http://localhost:9999/yourpage.html and watch magic happen.
full gruntfile here. full package.json here.
Here is a solution based on Gulp instead of Grunt and the following Gulpfile.js to get livereload working:
var gulp = require('gulp');
var connect = require('connect');
var connectLivereload = require('connect-livereload');
var opn = require('opn');
var gulpLivereload = require('gulp-livereload');
var config = {
rootDir: __dirname,
servingPort: 8080,
// the files you want to watch for changes for live reload
filesToWatch: ['*.{html,css,js}', '!Gulpfile.js']
}
// The default task - called when you run `gulp` from CLI
gulp.task('default', ['watch', 'serve']);
gulp.task('watch', ['connect'], function () {
gulpLivereload.listen();
gulp.watch(config.filesToWatch, function(file) {
gulp.src(file.path)
.pipe(gulpLivereload());
});
});
gulp.task('serve', ['connect'], function () {
return opn('http://localhost:' + config.servingPort);
});
gulp.task('connect', function(){
return connect()
.use(connectLivereload())
.use(connect.static(config.rootDir))
.listen(config.servingPort);
});
I know this is a little old but can help someone.
In the Gruntfile.js add "options":
sass: {
files: 'scss/**/*.scss',
tasks: ['sass'],
options: {
livereload: true,
}
}
In the index add:
<script src="http://localhost:35729/livereload.js"></script>
app.use(express.compiler({ src: __dirname + '/public', enable: ['less'] }));
That's the line in my app.js that enables less. How can I pass the { compress: true } parameter to it?
I also had this problem and thought this can be useful to share with others:
var lessMiddleware = require('less-middleware');
app.use(lessMiddleware({ src: __dirname + '/public', compress: true, optimization: 2 }));
More information and settings about the minify-process can be found in the Less-Middleware README.md
use less4clients with the compress option
I deprecated and removed the less4clients package which extends a express.js server with a less css rendering middleware to render less files to css on the fly (and cache the results in memory) in favor of a newer project of mine called DocPad that lets you use any pre-processor you want.
As of this time of writing, it does not have an easy to use express middleware like less4clients, however such a thing is on the roadmap soon. Instead you can use it standalone or via its API.
In hindsight I should have kept less4clients available and just stated in it's readme that DocPad is the new way of doing things, but I never realised less4clients was actually being used by anyone as DocPad has already gained so much attention.
Sadly, you can't and use connect's compiler to do it. The connect.compiler, which is what express.compiler is, only allows you to set which compilers to use, but not any options for the individual compilers. If you want to set less.js's compress flag you will need to create you're own middleware that user the less.js module.