On server side I am using Connect and Socket.IO. I want to serve my client side code (also CofeeScript) to be compiled (to JavaScript), uglyfied and gzipped. I looked for Conenct middleware to do this to me and found uglify-js-middleware and gzippo.
However I am not sure what's a good way to have it converted to JavaScript first (is there no API or something?) and whether I should use temporary directories for every step so I can use the src and dest options of uglify-js-middleware and gzippo or whether there is a better way to pipe it through all these things.
It's okay when this simply gets done when starting my application and so I don't care about checks or anything. I could probably use Cake somehow, but I don't really want to add an extra script for this and it would be cool if I could just pipe it so I don't have the need for temporary directories.
Is there maybe some kind of Middleware that does all of this? I really don't think I am the first one who wants to do this.
Oh and maybe the CofeeScript from a client side directory could be combined into one file, but I guess that's not really a problem.
Ah, if only someone had written a Connect middleware modeled on the Rails 3.1 asset pipeline... oh wait! I recently did: http://github.com/TrevorBurnham/connect-assets
It's pretty early-stage, but it does exactly what you want: compiles CoffeeScript files to JavaScript, concatenates and minifies them in production mode, and doesn't create new files (so no extra git diffs). Try it out and let me know what you think.
check out the compiler middleware: http://senchalabs.github.com/connect/middleware-compiler.html. It does exactly what you want.
app.use express.compiler
src: "#{__dirname}/public/scripts"
enable: ['coffee-script']
http://docpad.org can compile it on the server-side very intuitively
Has anyone seen Mincer?
https://github.com/nodeca/mincer
I'm choosing a solution now, so I haven't vetted it yet, but looks like it's strongly based on Sprockets, like connect-assets.
Related
The version of Node.js I used is 10.21.0. I modified BUILD.gn under deps/v8 folder: I set V8_TRACE_IGNITION=true and I rebuilt Node.js using ./configure after that. Then I run "node --trace-ignition xx.js". I expected to trace the ignition's behavior. But it said bad option. I was wondering where I did wrong.
I was wondering where I did wrong.
To get an answer to that, you'd have to describe exactly what you've done, e.g. by posting the patch showing your edits to the file.
That said, modifying BUILD.gn is not necessary to get --trace-ignition to work. Simply use gn args out/<your_output_dir> to edit your build settings as usual, and add v8_enable_trace_ignition = true.
I am working on transferring one application from rgen to Origen.
I added environment/j750.rb in my application.
added the below code into j750.rb
# environment/j750.rb
$tester = OrigenTesters::J750.new
in Target folder, I also added $test as below:
$tester = OrigenTesters::J750.new
however, when I tried to generate pattern, it still failed and showed'uninitialized constant OrigenTesters'.
When and how to initialize it?
Thanks a lot in advance!
Normally this is something that Origen users don't particularly need to worry about, if you add:
gem 'origen_testers'
to your application's Gemfile, then it will be required automatically and a reference like OrigenTesters in your environment file or anywhere else will just work.
However, I note that you mention upgrading from an rgen app, which means that your application must be very old and in fact may not even have a Gemfile.
If you contact me internally I can send you the link to our intranet page which has a guide on how to update these really old apps.
I'm looking for some middleware modules that allow me to render ".css" from ".scss", ".html" from ".jade", ".js" from ".coffee" on the fly without rendering to disk.
Every module I've encountered so far wants to write to disk before serving it instead of just streaming it.
Obviously this is only for local development since I'm not interested in dealing with file-revving and caching problems.
Answering my own question here:
The middleware to use is compile-middleware. Works fine by default with connect, but with express I had to modify it in order to not write headers (ugly i know, but time waits for no one) : https://github.com/airtonix/compile-middleware
implementation:
https://gist.github.com/airtonix/9601224
Original Credit goes to (You should try using this one first):
https://github.com/shinohane/compile-middleware
You should simply use a JavaScript task runner like:
Grunt: http://gruntjs.com/ or
Gulp: http://gulpjs.com/
These plugins could help you get started (gulp related):
https://www.npmjs.org/package/gulp-watch
https://www.npmjs.org/package/gulp-jade
https://www.npmjs.org/package/gulp-coffee
https://www.npmjs.org/package/gulp-sass
Here's a simple tutorial: http://www.codersgrid.com/2014/01/11/gulp-js-streaming-build-tool-beats-grunt-js/
I got nothing against grunt, both of them are awesome :)
Hope it helps!
socket.io source script goes like 70k, a great part is comments, spaces...
I need to reduce that script to a smaller size
Some scripts do not even have spaces and the code is all toghether, this reduces the script original size.
Where is the location of the socket.io script so that I can remove comments and spaces?
Or is there a socket.io allready whithout comments and spaces with a smaller size?
There is a setting in the socket.io configuration for this:
https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO
browser client minification defaults to false
Does Socket.IO need to send a minified build of socket.io.js.
You may also enable gzip compression on the library.
The client .js file is in *yourdir*/node_modules/socket.io/node_modules/socket.io-client/dist
There is one file called socket.io.min.js which is minified already.
The OP fixed the problem by going to /node_modules/socket.io/lib and editing 'manager.js', to set both "minification" and "gzip compression" to "true". They had to do this way because because they were using nowJS which indirectly uses 'socket.io'
This reduced the file from 70k to about 4k!
it seems socket.io is either returning some other file or returning by building at run time.
I replaced socket.io.js by renaming the min one. cleared cache of browser but still getting the old file.
I recently coded something where it wasn't known if the end code would reside in a subdomain (http://user.domain.com/) or in a subdomain (http://domain.com/user), and I was lost as to the best practice for these unknown scenarios. I could thinks of a couple:
Use absolute paths (/css/styles.css) and modrewrite if it ends up being /user
Have a settings file and declare a variable with the path (<? php echo $domain . "/css/styles" ?>)
Use relative paths (../css/styles.css).
What is the best way to handle this?
If there is any question about where something might be deployed, I would avoid absolute paths whenever possible, and if you must use them, make sure to construct them using the data in the $_SERVER superglobal. The value $_SERVER['PHP_SELF'] will contain the path and filename to the currently executing script, and you can then extract the path using something like:
$path = dirname($_SERVER['PHP_SELF']);
Likewise, the value $_SERVER['HTTP_HOST'] will contain the current host, and from those two together you can build the path to wherever you are. If you're using HTTPS you may also need to check the protocol in $_SERVER['HTTPS'].
With that said, it is still best to use relative paths and a simple file and directory structure whenever possible, since it makes everything more portable and easier to read. If, as in your example, you find yourself doing a lot of ../css/styles.css then you may want to reconsider how things are structured.
Mix of 2 and 3. Use paths relative to a set variable.