I am new to NodeJS and Grunt world. I am working on a project where we have multiple modules dependent on each other. So my question how can I automate my process of build for each of projects(modules)
like currently when I take update, I have to manually go in each of projects and have to run
npm install
and then
grunt
I think we'd need a little more information on what your project is and how its setup. Overall though, if you have several projects, each that uses grunt to build it, you'll need to run grunt for each one.
The way I handle this is to use TMUX, and more specifically TMUXINATOR https://github.com/tmuxinator/tmuxinator to setup workspaces for each of my projects. For example, I might type:
mux service-framework
Doing so could launch (for example), four terminals, my editor, start several grunt projects, and load a browser. Its a great tool for the situation you described.
There are a lot of tools for doing this type of thing, TMUX and TMUXINATOR are only one. Hopefully this helps a bit!
Related
I have a large project that contains multiple sub-modules, many of which are optional. And I have each sub-module sitting in its own folder with local package.json.
I'm trying to figure out the best way to create an integral package.json that would be able to run npm install on a specific subset of those modules.
Question
Is there a more civilized approach these days than just running npm install from every sub-module folder? I want to be able to halt the integral installation when it fails for one module, and hopefully do it on a declarative level within package.json, rather than implementing such logic myself. Plus, I want postinstall-s run on each package (if present), and then one of the integration package.
Other than that, maybe there is a better way today to manage such projects? I'm open to any suggestions!
I'm working on a web application that currently uses vuejs for part of its interface. The back-end is NOT in Node, so there is currently no package.json file or any tool from the typical npm stack in this repository.
We already have a bunch of non-npm dependencies that need to be installed in order to use the repository, so my coworkers aren't too open about the idea of adding another layer of complexity. I can't blame them for that, it's the reason why I use npm scripts and not even gulp in my other projects. I'm tired of spending hours learning and configuring build tools that never end up doing what I want anyway.
But since the vue-cli tool no longer includes the build command, I'm a bit stuck. Is there really no more CLI app to build vue files at all? And if so, what would be the smart way to use vue without webpack? Template strings are not maintainable at all, and <script type="text/x-template"> don't work when you want to use multiple components from multiple files in the same page.
I realize your question says 'without webpack' but you may be interested in backpack - a CLI app i came across for building Vue.js without requiring you to write any configuration code. It is basically webpack preconfigured as a minimalistic build system for Node.js. It provides two commands, dev for live reload enabled development and build for building you project.
I'm looking for the proper way to distribute/deploy a node.js app that would run as a small webserver on the user's machine.
Is there a stub method or install script or a "install wizard" that would download all node_modules dependencies, download the latest nodejs binary, set up the environment, etc... or I have to distribute it bulk with everything packed? Is there any guide for that purpose?
Edited :
You could install node and npm, download your dependencies by running npm install in the command line (first declare them within your package.json) only then users can run your script. This is how you do development in Node.js, or deploy to a development server. See using npm. You could automate that with a shell script if that is what you are after.
However, when distributing programs to end-users that might not be the best approach. Linux users are used to a package (.deb for instance) and Windows users are used to an .exe or a setup wizard.
That is why I recommended the tools below. I also assumed you were targeting Windows as this is less of a problem is unix-like environments.
If you want a single file (.exe), pkg and nexe are made for that purpose. These Node.js tools are used by the developer to compile JavaScript code into a single executable binary that is convenient for end-users and Windows deployment. The resulting .exe file is very light and does not require node to be installed on the end-user’s computers.
Electron along with electron-packager can produce setup wizards, but it installs a lot of files even for the smallest program. Your program will include all of node and webkit, that is why it produces heavy installs.
NSIS can also create a setup wizard, it is simple and does common stuff well (copying files, running shell scripts).
Original answer:
Short answer is: not really.
You have to keep in mind that Javascript is and has always been interpreted, so until recently never compiled to binary as you might do with other languages. Some exploration has been going on, but essentially you won’t get a "good practice" answer.
The long answer is, maybe, for some limited use cases:
There is the fresh new pkg that does exactly this, and it looks promising.
There has been nexe for a while, it works great for some use cases (maybe yours). Native/compiled modules are still an issue however.
Electron might work for a full blown app with a significant user interface, but it is not light or compact.
You could always use browserify to concatenate and uglify all your code with the modules you use and then make an installer with something like NSIS to setup node and your script. Native modules would still be a problem however.
So I've been reading about Gulp and Grunt, and how they can minify code, compress files, combine files into one, livereload etc. However, Meteor does all that already, with Isobuild.
The reason I'm asking is someone suggested using Gulp with Meteor, and I don't see a need for it. What are some possible reasons why I should run Gulp alongside Meteor? Or it is simply redundant?
If it is not redundant, what features does Gulp has that is not in Isobuild? And will the Meteor team plan to incorporate Gulp into its next versions?
Need is probably not the right word. Whether you want it or not is a different story.
As the comments mentioned above, Meteor include a very clever build system of its own called isobuild, which builds your WHOLE application for you. But there are certainly instances where you may want your own tasks which would best be accomplished through grunt or gulp. (The range of tasks you can accomplish with these is staggering, so I'm only going to list a couple simple common examples.)
The most obvious is going to be for assets you want to put in your public folder. But this is far from an exhaustive list of tasks that you may want to automate on a larger project.
Compile SASS files not using the libsass compiler (because it doesn't support all the features)
Compress and optimize images, svg files, favicons, etc.
Create multiple sizes / versions of images
Create Sprite Sheets
Concatenate and minify scripts in your own order / manner
Combine with Bower to manage front end packages that aren't available through atmosphere etc.
The way I would approach it is by putting all of this into the private folder, so its avoided by the meteor isobuild build system.
I believe these are enough reasons to not consider Gulp or Grunt redundant, and the range of tasks possible with grunt or gulp are so varied they can't all be listed here. Needless to say IsoBuild is fantastic for what it does, but would not replace everything possible with these task runners, and to my knowledge there are no plans to incorporate Gulp into IsoBuild. IsoBuild is core to what Meteor is, gulp and grunt are very powerful automation tools with thousands of possible uses.
Heres a really great starter for gulp, its super simple to get started with: NodeJitsu Gulp tutorial
So, sure, you don't need grunt or gulp, but they could certainly have a productive place in your meteor project and they're definitely worthwhile tools to get to grips with to streamline your dev processes.
If you would like to use either grunt or gulp, this is how I approach structure my project:
Project-folder
|__ webapp // my meteor app lives here
|__ assets // scss / images / svgs
|__ node_modules
| gruntfile.js
| .eslintrc
| package.json
I then build, minify, and process my assets, with my target directories in webapp/public
Note that with full npm support coming in Meteor#1.3 this may change, though I'm unclear about whether we'll be able to mvoe this into the project yet.
I'd like to make my Node projects a bit more idiomatic, making use of popular Node technologies like grunt. How should I rewrite my dependent shell tasks in my Makefiles in something like Gruntfile.js? There doesn't seem to be clear documentation on how to do this.
Is there another Node build technology I should be using? I would just write one-liner scripts in package.json, but npm doesn't have a way to specity that tasks dependent on one another.
Everything in grunt are tasks. You can use a task like grunt-shell to run your shell commands.
There's an open ticket for better docs about this.