I'm aware of the benefits that Yarn brings about and what it does that npm doesn't. I do have some doubts however:
Does Yarn use npm under the hood for some of the other commands that retain the same behaviour as npm?
If no, is there a reason why they were re-implemented in yarn and are there downsides to this approach?
No, it is a rewrite.
Rather than continue building infrastructure around the npm client, we
decided to try looking at the problem more holistically. What if
instead we attempted to build a new client that addressed the core
issues we were experiencing? Sebastian McKenzie in our London office
started hacking on this idea and we quickly became excited about its
potential.
-- https://code.facebook.com/posts/1840075619545360
It offers the same API (without some shortcuts if you notice). This is (I am guessing) because the original interface was simple enough and to ensure adoption.
It is much faster, solves typical problems of npm (undeterministic deploys mainly). This can be only achieved with a top-down rewrite, they also changed how deps are installed (fetch, calculate, download, link) so the logic is different.
The downsides of this approach is that it requires a huge amount of work. Normally you would just PR over the main repo, but given they wanted a whole different thing and Facebook has the means, they decided going solo.
Another big downside is that its benefits won't be immediately available for all the npm older users, since it is not an upgrade and it does not come installed with node.
I had a look at Yarn's source code and found that there was custom code written for each command: https://github.com/yarnpkg/yarn/tree/master/src/cli/commands.
I guess the downside to this approach is that in future when npm adds new commands, the Yarn team would have to track the changes and manually implement them.
Related
I am having difficulties in understanding why there is a trend/need to use npm to publish a package that is 100% client-side and has no dependencies. For example, a simple class that extends HTMLElement can not be used in Node and "installation" consist of adding script tag to HTML file, and yet there are thousands of packages. Is it only for bundling? Kindly excuse my ignorance, but sometimes it is important to know "why" before "how". Thank you in advance.
This is general question. I have checked similar questions but most of them are "how-to".
Bundling is an important advantage, not worthy of the "just" label.
It also provides versioning automation (one quick npm outdated and you can see if any of your dependencies have new versions out, and npm audit will alert you to security vulnerabilities).
NPM also has its own search engine so it provides discoverability.
I think it's fairly common to have miss-matched package dependancies between you main build and storybook which is a pain and always results in downgrading packages. Which isn't a good solution as you end up using older package versions and loosing out on features/fix from the later versions.
I have ran into this on a number of occasions and i have been trying to work out a better may to handle this. First i thought create a node or bash script witch swaps out you package.json depending on if you building the main project or running storybook. This of course is another crap solution as you end up being forced to git ignore your package.lock.json to avoid accidentally committing the storybook lock file and breaking the build on the production server.
There might be multiple ways to solve this issue and it would be nice to hear others for sure.
I haven't started a new web project for years, so the latest technologies went past me mostly unnoticed...
Now I need to create a little dynamic webpage, for which I mostly need jQuery and maybe one or two plugins. One of them requires a library called RequireJS, which I then had a look at and immediately fell in love with. Javascript just looked so much nicer suddenly! :-)
But... I had also found npm and really like the way of installing new packages. "npm install --save jquery" is just so nice and simple. Now, npm install tons of files in a node_modules sub-directory, which I don't really like. I only need one or two files per library!
So: is there a nicer way than npm to handle packages (i.e. only download the necessary files)? Especially one that works well with RequireJS? Or do I have to set up some other tools (found something called "grunt")? Can someone please give me a working example?
Thanks!
I'm a backend developer, and slightly confused by npm, bower, gulp, grunt, and Yeoman. Whenever I ask someone what their purpose is, the answer tends to boil down to dependency manager - for all of them. Surely, we don't need four different tools that all do the same?
Can someone please explain what each of these is good for in as few sentences as possible - if possible just one per tool, using language a five year old (with development skills) could understand?
For example:
SVN stores, manages, and keeps track of changes to our source code
I have used maven, Jenkins, nexus and ant in the past; maybe you could compare the tools above to these?
Also feel free to add other front-end tools to the list.
Here is what I have found out so far - not sure it's correct, though:
bower dependency manager for front-end development/JS libraries, uses a flat dependency list
npm dependency manager for node.js server, can resolve transitive dependencies/dependency trees
grunt runs tasks, much like Jenkins, but locality on the command line
Yeoman provided scaffolding, i.e skeleton projects
gulp same as grunt, but written in js only
node.js server for js apps?
git decentralized SCM/VCS, counterpart to svn/cvs
Am I close? :)
You are close!
Welcome to JavaScript :)
Let me give you a short description and one feature that most developers spend some time with.
bower
Focuses on packages that are used in the browser. Each bower install <packagename> points to exactly one file to be included for (more can be downloaded). Due to the success of webpack, browserify and babel it's mostly obsolete as a first class dependency manager.
2018 Update: bower is mostly deprecated in favour of NPM
npm
Historically focuses on NodeJS code but has overthrown bower for browser modules. Don't let anyone fool you: NPM is huge. NPM also loads MANY files into your project and a fresh npm install is always a good reason to brew a new cup of coffee. NPM is easy to use but can break your app when changing environments due to the loose way of referencing versions and the arbitrariness of module publishing. Research Shrink Wrap and npm install --save-exact
2018 Update: NPM grew up! Lot's of improvements regarding safety and reproducibility have been implemented.
grunt
Facilitates task automation. Gulps older and somewhat more sluggish brother. The JavaScript community used to hang out with him in 2014 a lot. Grunt is already considered legacy in some places but there is still a great amount of really powerful automation to be found. Configuration can be a nightmare for larger use-cases. There is a grunt module for that though.
2018 Update: grunt is mostly obsolete. Easy to write webpack configurations have killed it.
gulp
Does the same thing as grunt but is faster.
npm run-script
You might not need task runners at all. NodeJS scripts are really easy to write so most use-cases allow for customizedtask-automation workflow. Run scripts from the context of your package.json file using npm run-script
webpack
Don't miss out on webpack. Especially if you feel lost on the many ways of writing JavaScript into coherent modular code. Webpack packages .js files into modules and does so splendidly. Webpack is highly extensible and offers a good development environment too: webpack-dev-server
Use in conjunction with babel for the best possible JavaScript experience to date.
Yeoman
Scaffolding. Extremly valuable for teams with different backgrounds as it provides a controllable common ground for your projects architecture. There even is a scaffolding for scaffolds.
So, Since you have a good idea what each is, I will give you a simple workflow.
I use yeoman to scaffold a basic skeleton.
I am using node as the runtime for my application. ie. run node appname
I use npm to install node modules for helping me write the application in node
I might need some component from bower like front-end libraries so use bower to fetch these.
Now to do some repetitive task I will use grunt or gulp to write some tasks. So everytime I want to repeat it, say minimify my js files I call grunt/gulp and make them do it. Difference you ask, Gulp is stream based while grunt is task based.
I do version control using git to keep track of changes
Gulp vs Grunt: Gulp provides more flexibility with task automation, Grunt comes built in with a lot of functionality as per the common development practices. There are two main differences between Grunt and Gulp:
Grunt focuses on configuration, while Gulp focuses on code
Grunt was built around a set of built-in, and commonly used tasks, while Gulp came around with the idea of enforcing nothing, but how community-developed micro-tasks should connect to each other Read here
NodeJS: It is a Non-blocking server-side scripting language. Which means operations won't block further execution until current operation finishes.
Git: As you mentioned it is an SCM tool, a widely used one. As per the GitHub docs it is different from other SCM tools as data is never deleted.
Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
Read More
Bower vs NPM : Bower and NPM are dependency managers but Bower modules are for front-end development. NPM is a huge collection of modules to be used with NodeJS backend. This SO answer covers it better
I added some details:
npm is a package manager for javascript, npm is nodejs's package ecosystem, but it can be used only for front-end projects.
grunt & gulp are useful to separate and automate tasks like minification, compilation, unit testing on command line, it's a way lighter solution than (for example) visual studio as the process is only a separated (and usually lightweight) command line/process.
Regarding the differences between gulp, grunt and bower there is already a ticket: What are the differences between Grunt, Gulp.js and Bower? Why & when to use them?
Nodejs is more a javascript runtime. Node.js allows the creation of web servers and networking tools using js and a collection of "modules" that handle various core functionality and other core functions. Source
This ticket resumes the differences between Git and Subversion: Why is Git better than Subversion?
So to preface my question, I'm coming from a Java back-end developer perspective, where we use Maven to build. I have worked on testing on a server-side Node project we recently developed, but now I'm moving on to setting up testing on our front-end JavaScript client. I'm not very well-versed in front-end development and this is really my first foray into that.
All that being said, I'm thinking I'm going to use the following technology stack for our front-end testing: Eclipse IDE, Maven build process, Mocha testing framework, Chai assertion framework, Nock HTTP mocking framework, Sinon mocking/spying/stubbing framework, Rewire dependency injection framework. That all should be fine, and since that's the stack we use for our Node project, I would like to keep the front-end setup as similar as possible.
So, this is where my knowledge breaks down, though. I cannot seem to understand the difference in dependency management between our Node project and our front-end JavaScript project. I cannot see why I would not continue to use NPM, integrated into our Maven build, to handle dependency management and installation.
I see many people advocating Bower, but after looking at its page and docs, I still am not seeing what niche it fills that NPM would not. I am seeing a lot of adamant rejection of NPM insofar as browser dependency management goes; the main reasoning being that NPM is designed for server-side Node projects, and not for the front-end space. But who cares? Regardless of its initial design's intentions, if it does what I need it to do, where is the downside?
Please approach this "question" as if I am a complete newbie. I have realized as I've gone through this process and research, that I have very large dearths of knowledge in regards to the front-end side of things. With that being said, be as specific and thorough as possible in your answers, please. I would be happy to share project configuration and such, as needed, in order to help paint a picture of the space I'm in. Thanks for any feedback!
Bower and NPM do work differently.
NPM is very powerful and great at what it does. However, you won't find many client-side packages in there; most of them are there because they work in Node too. (For example, Underscore.JS and the JADE template engine.)
That's why you have Bower, which has the majority of the client-side packages. It has many jQuery plugins, templating engines, CSS frameworks, etc. Don't expect to find such packages in NPM.
You can work fine with both. I do so. :)
Traditionally, many web development projects combined npm and Bower. npm was used to manage back-end dependencies, while Bower was used for front-end dependencies. In fact, you needed to use npm in order to install Bower in the first place.
Although Bower’s advantages were compelling, they are now provided by other tools, namely npm, Yarn and webpack. While the open source project is still maintained, its creators decided to deprecate it, and advise how to migrate to other solutions—namely Yarn and webpack.
more explanation