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.
Related
This has always been a thought of mine. I understand the difference between a dev dependancy or a dependancy not being one. Is there a way however of finding out which one is needed only for dev, not knowing or being familiar with some the packages used?
Although there's no guarantee that the listings in package.json aren't erroneously classified, looking in dependencies and devDependencies in package.json is the closest thing there is to an easy way to determine if a package is used only for dev or not.
I'm using git submodule to build and shared components between projects. The project is not in production yet, so, at this point submodule is serving well.
But I'm concerned about maintenance and deploy, would be a good idea transform it into a npm package ?
An npm package will allow fragmentation across different package versions. On the other hand, git submodules have a bit of a learning curve, and the tooling is really not that good. With git submodules, you have all the source in one folder.
If it's at all possible, I'd recommend using a plain monorepo for all projects. You may need to create build time variables (via babel plugin/s), you may need some sort of "live config" get served from the backend. I worked with git submodules for a year and I've recently worked with a project that uses npm to share code.
I would recommend using only one git submodule, for all shared code, instead of several submodules. I would strongly consider using lerna, and use your one git submodule to track lerna's packages directory. And if the team decides they don't like git submodules, you can easily make this repo a sibling git repo, instead of a submodule. However, above all this, I'd recommend using a plain monorepo.
Here's a great talk on monorepo's from Netflix: https://www.youtube.com/watch?v=VNqmHJtItCs (strong focus on discouraging npm-style packages)
Here's google's infamous monorepo talk: https://www.youtube.com/watch?v=W71BTkUbdqE
This is a great site to read to help you think about good development flows: https://trunkbaseddevelopment.com/ (it primarily advocates for the monorepo approach)
If you are developing software for different clients(different people/companies paying you for similar projects), and have some agreement that they should be at least ~80% the same, you may really enjoy using build flags to help get started on splitting functionality, but I'm sure you should very proactively keep the code around the build flags clean, and refactor into re-usable components/packages. Give each client some sort of build-flags.json. Build flags should be named for features only, which in theory can all be individually toggled. Some code may be totally custom for each project, in this case, you may want to consider using dynamic imports, but generally this is a pain point I have yet to fully cross, although I have plenty of unrefined ideas around this.
If a monorepo is just not happening, I would actually recommend using npm packages+separate repos over git submodules, assuming you can do good semantic versioning of the package. (And, yalc seems to be a good tool for linking together packages, as opposed to the standard npm/yarn link)
My findings after trying both lerna, npm workspaces and git submodules. I find it is not a case of the one vs the other.
The reason why I say this is because one can have submodules that are part of the monorepo. Doing exactly this made my development experience better as I could clone an existing project and actively develop it within the bigger project (monorepo). I could then contribute back to the cloned project once satisfied with the changes. This is something that you cannot do with npm workspaces alone. Hence my argument that it is not a case of one vs the other. They solve different problems and can therefore complement each other.
Before using npm workspaces I would use npm link all the time. npm workspaces makes this use-case of developing with multiple packages more convenient. Even when the team you work with does not use a monorepo; you could use one to develop multiple packages and test them in conjunction. Once satisfied, you can push the individual repos. This is something you cannot do with git alone.
Maybe you can think of more novel ways of combining the features of npm and git.
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.
Lets say I am working on a library that will be consumed by other developers. MyPackage has a dependency on moment. The developer that consumes my package also has a dependency on moment. So moment will exist as a "dependency" in both library package.json and application package.json (and thus get packaged twice). Is there a way to package it just once? If the consumer has it, use theirs, else use mine?
It's already happening by default on fresh installs if dependency ranges match.
npm v>=3 does gang the dependencies, depending on the installation order and depth, see here.
Also, if you kept working on the same folder for a while, there might be some cruft, which could be wiped using npm dedupe, see here.
In theory, moment should not be duplicated if both your library and developer's library are consuming the same version ranges of it. At least if npm dedupe is called or node_modules are wiped and npm i-nstalled.
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.