I understand, in general, the most frequent way Grunt is used on Heroku -- load the buildpack, specify your grunt heroku task(s), and include any Grunt plugins you want to use on the Heroku dyno in your package.json:dependencies.
However, I find this to be a rather poor solution, because it miscommunicates about my app. My Grunt plugins are all more like devDependencies, as I will only run anything with Grunt one time (per deploy). My app doesn't directly depend on them to run, as it's mostly minification and template compilation.
I'm also trying to keep compiled files (e.g. .css and .html files when I'm writing in Sass and Handlebars) out of source control, so pushing them over from Github is possible but definitely not what I want.
Is there a way to do all of the following?
exclude .css and .html files from Git
write stylesheets and markup using Sass and Handlebars
push a basic Express app containing these files to Heroku
have Heroku run a server-relative version of my grunt build task (naming it whatever is necessary is fine) to compile and prepare all of the views and assets before launching the web: process
have Heroku's Grunt task intelligently understand that I just want some pre-launch compilation so it will look at devDependencies and install the relevant ones in a perhaps-temporary kind of way
launch the Express server via the web: process
I'm fine with having to write my own buildpack, or whatever needs to be done to do this (what I perceive to be) the right way.
I created the buildpack heroku-buildpack-webapp-client that supports grunt, compass/sass and installs your devDependencies. Maybe you can use this one or have a look at the bin/compile script to see how it works.
Related
I recently used "heroku run" and looked around inside my package.json nodejs app, the slug is NOT minified in /node_modules . I am using the standard "heroku/nodejs" buildpack. Looking around, has nobody ever minified their node apps? While I could write a postbuild shell script to run terser on the whole package tree, why isn't this done automatically by heroku and google says nobody does it?
I know that could be multiple answers for this question but I would know how i can fast setting up project with Bootstrap and Sass.
I had never used node, npm, grunt or bower, I've installed all already but i can't really find a good tutorial for:
Setting up the project structure
Auto compile sass files on save
(Maybe) Live reload in chrome?
I would suggest not using any boilerplate for your first project as you want to get into the "guts" of it, and once you are familiar with basics, then you can try boilerplate and see what they can do for you.
Few tools you would need to setup a project from scratch includes: Node's npm, Bower, Gulp (for example).
After you have those installed, you can dig in into creating your first project.
1) Initialize your npm project
2) Pull the packages with Bower (Bootstrap scss for starters)
2a) Pull the Specific Bootstrap 3 SCSS port
3) Configure Basic Gulp-scss config for your SCSS needs.
Basic idea behind Bower is that you have unmodified source of plugins/3rd party js/css in bower_components folder, and you use those files to compile a production ready files (js/css). What this means is that your bower_components folder is a "src" folder, and you have to add your "dist" or distributable files. Gulp helps with this part.
For the project structure, further readings and improvements on gulp tasks.
Once you have basic working project, you can try expanding your gulp-config with, like you mentioned Browser Sync and others.
I did compile a "general tasks" gulp file that i use from project to project. You can take a look here and use it if you find it fits.
Hope it helps.
You can try using Aldryn's boilerplate:
https://github.com/aldryn/aldryn-boilerplate-bootstrap3
Documentation
I have the Meteor app setup with such folder structure. I am not able to get the sass or scss file to create the appropriate css on its own and serve it to the client.
What should I do to make sass work as I prefer sass over scss.
Meteor supports less and stylus out of box my issuing meteor add less or meteor add stylus in your project root directory.
there is also a third party package repository (to be rolled into meteor core in the near future) on which you can find alternatives to many requirements.
For example, there is a third party scss package you can add to your project with meteorite add scss.
Now, the meteorite command here belongs to an npm package that interfaces your app to the atmosphere package repository as well as provide some deeper packaging structure to your app.
When you add the scss package, like in a typical meteor application your coffeescript, handlebars,jade,less,scss,javascript etc files will be compiled/bundled at deploy time and at each save afterwards and be placed in a hidden directory. So you will not be seeing your compiled css alongside your scss files, but the css will have been sent to the browser.
I am new to Node.js programming and I have recently created a sample working web application using (express, backbone & other complimentary view technologies, with mongoDB). Now i am at a point where I want to deploy the same on a staging environment and I am not sure how to package this application and distribute the same. [I can take care of mongoDb and setting it up seperately]
I am from Java world and in there we create jars for reusable libs and war/ear packages for web applications which is deployed in a servlet container. Now in this case since node.js itself acts as a web container as well, how do i package my webapp?
Is there any standard format/guidelines of packaging node webapps built using express? (Is there a similar jar/war packaging systems for node apps?)
How do I deploy it once packaged? Would it become an exe, since it is also its own container?
PS: As of now I am thinking of just manually copying all the required source files into the staging environment and run npm commands to download all dependencies on that machine and then use 'forever' or some other mechanism to run my server.js. (Also, add some sort of monitoring, just in case app crashes and forever fails) I am not sure if that is the right way? I am sure there must be some standardized way of addressing this problem.
Deploying Node.js applications is very easy stuff. In maven, there is pom.xml. Related concept in Node.js is package.json. You can state your dependencies on package.json. You can also do environmental setup on package.json. For example, in dev environment you can say that
I want to run unit tests.
but in production;
I want to skip unit tests.
You have local repositories for maven under .m2 folder. In Node.js, there is node_modules folder under your Node.js project. You can see module folders with its name.
Let's come to the grunt part of this answer. Grunt is a task manager for your frontend assets, html, javascript, css. For example, before deployment you can minify html, css, javascript even images. You can also put grunt task run functions in package.json.
If you want to look at a sample application, you can find an example blog application here. Check folder structure and package.json for reference.
For deployment, I suggest you heroku deployment for startup applciations. You can find howto here. This is simple git based deployment.
On project running part, simply set your environment NODE_ENV=development and node app.js. Here app.js is in your project.
Here is relative concept for java and nodejs;
maven clean install => npm install
.m2 folder => node_modules(Under project folder)
mvn test => npm test(test section on package.json)
junit, powermock, ... => mocha, node-unit, ...
Spring MVC => Express.JS
pom.xml => package.json
import package => require('module_name')
There is no standardized way, but you're on the right track. If your package.json is up to date and well kept, you can just copy/zip/clone your app directory to the production system, excluding the node_modules.
On your production system, run
npm install to install your dependencies, npm test if you have tests and finally NODE_ENV=production node server.js
Some recent slides I considered to be quite helpful that also include the topic of wrappers like forever, can be found here.
Hope this might be helpful for somebody looking for the solution,Packaging of Node js apps can be done using "npm pack" command.It creates a zip file of your application which can be run in production/staging environment.
Is there any standard format/guidelines of packaging node webapps
built using express? (Is there a similar jar/war packaging systems for
node apps?)
Yes, the CommonJS Packages specification:
This specification describes the CommonJS package format for
distributing CommonJS programs and libraries. A CommonJS package is a
cohesive wrapping of a collection of modules, code and other assets
into a single form. It provides the basis for convenient delivery,
installation and management of CommonJS components.
For your next question:
2. How do I deploy it once packaged? Would it become an exe, since it is also its own container?
I second Hüseyin's suggestion to deploy on Heroku for production. For development and staging I use Node-Appliance with VirtualBox and Amazon EC2, respectively:
This program takes a Debian machine built by build-debian-cloud or
Debian-VirtualBox-Appliance and turns it into a Node.js "appliance",
capable of running a Node application deployed via git.
Your webapp will not become an exe.
few ways to approach this:
Push your code into Git repository, excluding everything that isn't your code (node_modules/**), then pull it in your staging environment, run npm install to restore all dependencies
create an NPM package out of it , install it via npm in your staging environment (this should also take care of all of the dependencies)
manual copy/ssh files to your staging environment (this can be automated with Grunt), than restore your dependencies via npm
I used zeit's pkg module. It can create cross platform deliverables for linux/win/macos. Actually used it in production and works fine without any issues.
It takes in all the js scripts and packages it into a single file.
The reason I used it is because it helps in securing your source code. That way in production at customers environment they will have access to application but not the source code.
Also one of the advantages is that at production environment, you do not actually need to have the customer install node.js as the node binaries also get packaged inside the build.
https://www.npmjs.com/package/pkg
I've got a Node app that I'm deploying to Heroku. Their docs say it's best practice to check in your node_modules directory (i.e. don't gitignore it), for faster deploys and for dev/prod parity.
In my package.json, I've got loads of devDependencies (mostly Grunt plugins and all their deps) and a few regular production dependencies like Express. Heroku only needs the production deps. I'd rather not check in all my dev deps, because they come to about 50MB.
Is there some way to have a separate folder for you dev deps, e.g. node_modules_dev? If this was possible, then I could just add node_modules_dev to my .gitignore, and check in the regular production node_modules directory as per Heroku's advice.
Is there any way to do this? Or can you think of another way to do what I'm trying to do?
I use a CI server to build, test, and deploy my files — so I was looking for a similar solution that would prevent me from needing to deploy extra dependencies and/or re-build on Heroku.
After all my tests run, I run npm prune --production, which removes devDependencies from node_modules, and then I push the result to Heroku.
No extra files go to the server, and deployment times are much faster since Heroku avoids having to build all the binaries usually found in Gulp/Grunt plugins.
If you don't mind checking them in anyways, and your only concern is the resulting slug size (i.e.: not your git repo size, or transfer of that repo to Heroku), then simply add the relevant node_modules to .slugignore.
Docs: Ignoring files with .slugignore.