Lately I have been wondering if there is any way to use bower or npm only as a consumer.
Let’s say I am not really interested on developing the package further, but simply using it on my website/application.
So as I would first think:
npm install jquery
I have tried with the flag --production but the same structure was downloaded.
However, that brings me a huge tree of files and the only one I would need is the jquery/dist/jquery.min.js file.
Same goes for bower:
bower install jquery
Again, an expensive list of files, including src folder with a lot of dev-only related files.
I am sorry if I am wrongly assuming package managers behaviour here, but it would be interesting to know how to use these package managers as a simple end-user instead a developer in order to keep my project dependencies updated.
At the moment, I feel that it's just too much for what I need, and that by simply copying jquery.min.js over to my project src folder, it would be much cleaner/simpler.
If the concept of both npm and bower is different and someone can point it out it would be appreciated as well as any tips for an alternative package manager that only imports essential production files.
Apparently Volo does exactly what I was looking for following a concept where JS libraries should be kept as one single JS file.
Here, more information about the project’s design goals.
Related
As title indicates, I'm working on a project where different members have used different tools (NPM and Yarn) for handling packages and modules etc.
We aim to transition to use ONLY Yarn (not our decision). Would anyone be able to share resources detailing how to accomplish such a thing? Or help quickly walk me through the steps?
I tried googling for answers but every single result is yet another article explaining why you should ditch NPM/Yarn and move your project to Yarn/NPM, without explaining the steps one would need to take to move from using both to just one mid-project. Thanks!
It looks like Yarn has a page talking about how to migrate to it from NPM:
https://yarnpkg.com/lang/en/docs/migrating-from-npm/
In most cases, running yarn or yarn add for the first time will just work. In some cases, the information in a package.json file is not explicit enough to eliminate dependencies, and the deterministic way that Yarn chooses dependencies will run into dependency conflicts. This is especially likely to happen in larger projects where sometimes npm install does not work and developers are frequently removing node_modules and rebuilding from scratch. If this happens, try using npm to make the versions of dependencies more explicit, before converting to Yarn.
As of Yarn 1.7.0, you can import your package-lock.json state, generated by npm to Yarn, by using yarn import.
They use many of the same files and structures. The important thing is to check-in the yarn.lock file and make sure everyone is installing using Yarn instead of NPM.
If you have a build server, you could probably use it to enforce those dependencies, but it would be more work.
After I am installing a root library, such as npm install aws-amplify, sometimes it seems that I need to install its sub library such as npm install #aws-amplify/cli. Why did not npm install aws-amplify install every sub library within it?
What's the npm packaging and installing rule here? can someone help me clearing understand that?
You are mixing up 2 different syntaxes. The #namespace/package is relatively new. It used to be just package, and some packages still use this. In the old way package tend to name themselves 'namespace-package' as some sort ofworkaround.
But that is not your question. Your question is 'why do they even do this?'.
Why wouldn't you just download all the npm package out there? Then you have and can use everything, right? As you can imagine this doesn't make much sense, you will only want to download and use what you need. Think of this quote from Joe Armstrong:
You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
The quote is a entirely out of context since it is more about not using classes, but it still kind of applies to this. At lot of packages will offer you a core package and the option to add sub-packages based on your need. Like in your example, someone might not need #aws-amplify/cli, this way he doesn't have to download it.
I'm trying to build an aspnetcore mvc-app from a console-app and I'm no comfortable with implementing the Program.cs and Startup.cs classes, adding the controller, action and view.
So now I'm ready to start working with frontend and I thought that I should learn a good package-manager and workflow to add front-end packages to wwwroot/lib. As I've understood it npm (and webpack) are highly recommended for this (unless I'm mistaken).
I have a hard time finding a tutorial teaching me how to do this though, most of them introduce several concepts (Angular, Typescript, Yeoman Gulp, etc.) that confuse me as to whether I'm learning what I'm looking for.
I asked this question and thought I'd start with a workflow rughly like this:
Run npm init in my project folder (adding a node_modules folder to the project)
Run npm install bootstrap --save. This will install the NPM module in a node_module folder.
Manually copy the bootstrap-module from my node_module to wwwroot/lib through the cp command.
Now this doesn't feel right or "correct" I'd love to look into WebPack which was suggested in my previous question as a way to do bundling (which I must admit I haven't learned yet) for step three.
So my general question would be if this seem to be a reasonable approach to start out with or if it's seriously flawed compared to how it's supposed to be done?
A specific question is what is the npm entry point? The default is Index.js but is this right for a dotnet mvc-app? As you might notice I'm a bit confused as to where to look for answers for my problem so hope if there's no good answer you might be able to point me in the right direction? :)
EDIT: PS, Using Visual Studio Code (my computer can't handle Visual Studio) so can't use tools unique for VS.
I use npm scripts a lot for my javascript/node projects (npm start, npm test, and npm run build and others), and I was wondering if there is something similar for elm-packages, or if we should use npm scripts instead, and if I have to do it, why do we need a package.json and a elm-package.json?
The quick answer is that (as of May 2017) there's not support for this in elm-package.json.
As for the future: Evan Czaplicki has said on elm-dev mailing list that the file format and functionality will get revamped a little bit (probably with the 0.19 release), but most probably mainly with regards to application vs. library distinction. Based on that, I don't think elm-package.json will get this functionality anytime soon.
I think most devs have some node stuff running to handle their dev environment (e.g. webpack stuff) so you will always have package.json available for such scripts anyway.
There is a question about whether elm should embed its dependencies within package.json but, while most dev instances would have package.json, anyone just trying out with elm-reactor would not. So I think the present situation is here to stay, and enables you to do what you want.
This is more of a conceptual question.
In Package.JSON file we have devDependencies and Dependencies. I understand what each is for. But are these in place simply to make it clearer to other developers what the dev dependencies and the production dependencies are when we distribute our files? If we weren't distributing our files would it make a difference if we put the devDependencies in the dependencies section? In my mind it shouldn't because the package.json is just used for npm installation and when we run our app through a bundler such as webpack it will only bundle up the modules required for deployment. In fact if we are not distributing our files theoretically do we even need a package.JSON file (although I see why we would want one so that we can move files from one place to another easily and just reinstall modules at the other end).
I believe this is a unique question because it asks not just what is the difference between dev and normal deps, but theoretically, is there are difference between the two if you don't publish. Allegedly duplicate answer does not talk about that, yet it's important for people's proper understanding of npm.
Back on your questions:
But are these in place simply to make it clearer to other developers what the dev dependencies and the production dependencies are when we distribute our files?
No. NPM will behave differently depending is it dev or "normal" dep. See more on alleged duplicate's accepted answer. For example, when you install published package, install doesn't install dev dependencies unless you explicitly request via a flag.
If we weren't distributing our files would it make a difference if we put the devDependencies in the dependencies section?
No difference functionality wise only if you don't publish. Besides being a bad practice, difficult to maintain and so on, of course.