I've been trying to get familiar with a few popular Javascript repositories on GitHub. It seems that I often pull down the repository, then run into an issue with some sort of dependency. Usually this will be something encountered during the npm install or the grunt run.
To be clear, these are not node packages that would be installed by npm, rather console dependencies that some grunt packages seem to need in place and to be available in the system's path variable.
I've had to install Git, Java, Bower, PhantomJS, and other packages after cloning new repositories and trying to build them. My question is this: Is there a standard set of console utilities (beyond just nodejs and those things that are installable via npm) that are expected for doing Javascript builds via Grunt?
Related
I come from Java world and I'm used to code with Maven and Eclipse, which makes very easy to work with local dependencies as the IDE + M2Eclipse plugin is able to resolve dependencies from the workspace.
Now that I'm developing in JavaScript with NPM and VS Code, I find that you have to use manual options such as npm link + npm build --watch or npm pack + npm install <path> to work with local dependencies.
I'm developing an Angular application which codebase is split in different Git projects and npm packages, so we waste a lot of time testing local dependencies and also it is error prone.
I guess that this is caused by the different nature of JavaScript and Npm but, is there any plugin or option to ease local depevelopment in VS Code?
EDIT: I have seen this article about Yarn Workspaces and it looks like what I'm looking for... anything similar in npm? I see Lerna is an option but only for monorepos, I have separated Git repos for each library.
EDIT2: To clarify the problem, lets say I'm developing two Angular libraries, each on a different Angular workspace. Library A depends on library B. I use VS Code workspace to have these two Angular workspaces open at the same time and edit them together. If I change library B I have to build it and link it so that I can test the changes locally in library A before publishing. This is what "resolve dependencies from the workspace" solves in Eclipse + M2Eclipse in Java, the IDE just builds and links projects together. Thats what I'm looking for in VS Code + NPM in Angular.
EDIT3: New workspaces feature in NPM 7 looks promising, I will give it a try. Any thoughts about it?
I'm a little confused as to why I can't get my Gruntfile.js to run, here's the rub:
I installed grunt globally using npm. It lives in my /usr/local/bin/ directory, here it is:
Previously, I'd installed node.js using homebrew, then grunt with npm. Other issues led me to uninstall node via homebrew & reinstall node directly from the disk image node provides.
In my web project's index, there's a Gruntfile.js script that rebuilds my jekyll site everytime live-reload updates. When I run grunt, I get this message:
What I'm trying to wrap my head around:
Why isn't /usr/local/bin/grunt a valid path? Grunt exists at that location. My guess was that running grunt locally, from within my website's index, would fix things.
There's a node_modules folder there & everything was working fine before after all. I found this link, and tried running \grunt to bypass the bash alias, but that had no effect.
Any advice/suggestions are much appreciated! I feel like an imbecile using things, breaking things & not understanding why/how. Eager to finish my project, get a paycheck & finally have time to learn the ins and outs of terminal, bash & popular package managers so I don't run into these sorts of problems...
After discussion with OP, I find this is a Node.js environment issue. After install - do something - uninstall - reinstall in another way - do something, somehow, when npm install -g XXX is executed, the symbolic link is created and point to some place, but the package is installed some where else. That's why OP see /usr/local/bin/grunt but cannot run it.
I've recommended OP to clean up all Node.js stuff, make a clean environment and start right from the beginning.
I am learning to use webpack and generally getting in to the Javascript world, including npm.
Several answers deal with --save vs --save-dev when using npm install. My understanding is that their use (and updates to package.json) is actually useful when recreating either a run or a dev environment via npm install <the package being developed or ran>
--save is used to save packages needed to run the app in node.js, that is on a server
--save-dev is used to save packages needed to develop the app
a bare npm install <module> just installs the package, without enabling the possibility to install it somewhere else though the appropriate entry in package.json
Therefore, in a webpack context, is --save ever used? I belive not, because what is created is a JS bundle which is then included in the HTML file, and ran in a browser. In that sense, there is never a need to "save modules needed to run your app".
In the same vein, --save-dev is useful (again, in a webpack context) at it allows someone to develop elsewhere (in that case both modules in the app (say, moment.js) and logistical ones (say, gulp) should be installed with --save-dev, right?)
Finally, a bare npm install <module> is also possible (although less useful) is the development is not intended to be done elsewhere (the modules are still installed but no mention of this fact is made in package.json).
Is this correct? Specifically, is the assumption of a lack of --save in a webpack context true?
Anything that it utilised in the production build of your application should be listed in save. For example if you use React, your application utilises React in the final production build. It doesn't matter that your file is bundled but the fact that it's heavily relied upon running when compiled.
Anything that is used during development should be listed under devDependency. In this example, once WebPack has finished bundling your files, we no longer care about WebPack because it's not apart of the final compiled file.
--save-dev : Anything that is used during development such as Unit testing frameworks or bundlers etc.
--save : Anything that is used within your application such as Axios, React, Vue or Chart.JS etc.
I noticed there is a big discussion about what is the best build tool e.g. Grunt, Gulp, Webpack, etc. I first opted for Gulp, I read its documentation and started making my first gulpfile.js and it worked I started improving it with the time
But I also noticed that npm can be used as a build tool, I could do the same things I did with my gulp configuration using npm, it took me less time it was just command line instructions, no extra documentation to read.
These are my two configuration files. gulpfile.js and package.json
They do almost the same, basic tasks such as concatenation, minifications, transformation from JSX to javascript, etc, one using Gulp and the other using npm. My question is if are there tasks that I could not do with npm only? in the way that will force to use Gulp or another build tool.
Thanks in advance
Your question infers that npm scripts are less powerful or more constrictive than task runners like Gulp. They're not. With npm scripts you can:
Make direct command line calls
Reference npm packages in your npm script
Call separate JS scripts that leverage any npm packages you may need
Call shell scripts, Ruby scripts, Python scripts, and so on.
In short, there's nothing restrictive about npm scripts. So while no technology can do everything, npm scripts are capable of doing everything Gulp and Grunt can do. At their core, npm scripts, Gulp and Grunt are all just opinionated ways to run code.
What is the best way of sharing code between frontend and backend using javascript, specifically saying between nodejs and angularjs?
Thing is that we are using same enums and constant values such as error codes in both backend and frontend. Right now we just copy&paste each change to both platform which isn't a good solution. There are also some services that could be shared.
I have seen libraries such as browserify; but thats not exactly what I am looking for. I am looking for a solution similar to maven dependency in java. In java, libraries can be shared easily using maven, whereas I can't find a similar way of doing that in javascript.
Is there a way to isolate these services and give them as dependency to nodejs using npm and to angularjs using bower independently? Or what are the ways for sharing the same code between frontend and backend?
There are several ways to do this. The first is that you can make a new package which is required via bower for the front-end code and via npm for the backend code. I have several packages published to both systems.
Install with Bower -- information on how to install modules that aren't in the registry
NPM Install docs -- all the ways to install with npm (private github with auth: git+ssh://git#github.com/[org]/[repo])
Just create a new module with your shared data and install it using both package managers. Both of them allow you to install an unpublished module so if it's private data you can keep it as such.
If your front end requires require.js you can use something like amdefine to make it available to your node backend, or if you're just using legacy window code you can do something like:
var mydata = {};
if(typeof window !== 'undefined'){
window.mydata = mydata;
} else {
module.exports = mydata;
}
If you are sharing a lot of data though I highly recommend looking into browserify to write your entire codebase in commonjs and using browserify to generate your client bundle. There is a laundry list of resources about using browserify, including stuff on how to use browserify and angular together
Disclaimer - I'm still developing this approach and it's a little manual.
I did this using npm, an npm cli called pac, and bower. Pac let's me avoid using npm install in production by keeping the modules as .tgz files (committed to project in source control). With pac, when someone checks out the node project, they run pac install then npm rebuild instead of npm install.
My shared code is kept in a directory (my-module). It has both package.json and a bower.json.
My consuming node app has a package.json dependency for:
"my-module" : "x.y.z"
My consuming client has a bower.json dependency for:
"my-module" : "../relative/path/to/my-module"
When I make updates to my-module, I update my node app by:
Making a tar.gz of the contents of my-module:
tar -czvf my-module.tar.gz -C my-module
Removing the old version from the node app's node_modules
Rerunning npm install path/to/my-module-tar.gz
Rerunning pac (this makes a .tgz of node_modules/my-module)
Committing the updated pac .modules/my-module.tgz
I update my client by:
Removing the old client/bower_components/my-module
Rerunning bower install or bower update