Develop Reference

Install vuex without npm or yarn?

Hey I want to install vuex in my Vue3 project. Because of several reasons I have no possibility to install it with npm or yarn. I already googled for solutions but it seems like there aren't any. Had someone of you maybe the same problem or an idea how to fix this?

You should be able to use with by loading it from a "CDN" as below
https://unpkg.com/vuex#4
Unpkg.com provides NPM-based CDN links. The above link will always point to the latest release on NPM. You can also use a specific version/tag via URLs like https://unpkg.com/vuex#4.0.0/dist/vuex.global.js
For more info refer to installation section of Vuex docs

Deleting `package-lock.json` to Resolve Conflicts quickly

In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.
Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?

Yes, it can and will affect all the project in really bad way.
if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"
even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.
Conclusion: don't ever delete package-lock.json.
Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.
In your case you better do next way:
fix conflicts in package.json
run npm install
As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.
Per docs npm will fix merge conflicts in package-lock.json for you.
[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.

Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.
By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).
Anyway there is already a standard solution for it.
Fix the conflict inside package.json
Run: npm install --package-lock-only
Check out this link for more info:
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts

I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.
Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver
Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.
Edit: This repository is now archived and read only.

npm i --force does the work for me

local change in node modules file

I need to make some changes in one of my node module package. But the problem is that if I am changing any file inside node modules folder then the changes won't be available to the other developers as it won't be checked in. Others will install it via package.json.
Is there any way I can include the file in my application instead of node modules and will it be a good approach?
Kindly suggest if there is any other alternative.

You have three options
Send a PR to the actual npm package, if the change is like a bug fix or enhancement that aligns with the actual packages goal.
Fork the package repo, and make changes and use it in your project as a dependency, in case you are adding changes that does not align with the goals of the actual package
move the package code into your source code, and use it as source code rather than a package from npm

you can make a fork of the project, then inside your package.json add the dependency as
"package-name": "<your username>/<your repo name/probably same as package-name>#<branch>",
also you can install it using yarn/npm
npm install --save username/repo#branch-name-or-commit-or-tag
as show this link
this is all, run yarn o npm install and you'll get your changes, please make a PR to the original author and when this will be accepted you can return

Webpack: ChunkRenderError: No template for dependency: TemplateArgumentDependency

I'm attempting to update my Phenomic install to webpack 2 beta 13 (I've heard people suggest the beta is pretty stable now).
I get the follow error when trying to build version using the DedupePlugin, but it seems to work if I remove it. The error is:
phenomic:builder ChunkRenderError: No template for dependency: TemplateArgumentDependency
at Compilation.createChunkAssets
Phenomic includes webpack itself and sets up part of the config. You can run a build using Phenomic and it will also take custom webpack settings from your own generate project. A default project is created for you to modify when you initialise Phenomic.
I've tried changing the version numbers to "webpack": "2.1.0-beta.13", under Phenomic's peer and normal dependencies and rebuilding with it npm linked. I also made a few of the changes needed for updating webpack 1 to version 2.
I've also deleted node_modules in both Phenomic and my project directories, which did not seem to help (and took a long time ;).
I've browsed through this thread which was webpack 1 related and there is some suggestion of dependencies causing multiple copies of webpack. Any ideas are appreciated.
Update:
I made my webpack 2 changes in Phenomic and setup the default project. It seems to build (with some CSS issues), so the problem seems related to the more complex project I am using Phenomic with. Maybe another dependency is bringing in another copy of webpack.

It seems this is npm link related as I installed installed Phenomic from my file system and the issue disappears.
I also noticed there was a global copy of Phenomic, which is also possibly related to npm link.
Another tip I found was npm ls is useful finding what dependencies are in use. You can pipe the output to a file if you want to read it in an editor.

Developing an npm package and a project that depends on it at the same time

The setup/workflow:
Project A relies on a custom npm package in package.json.
As engineers work on Project A, they will inevitably be making changes to the custom npm package as well. This is streamlined by having them clone down both the project and custom package repos, then applying npm link.
(source: http://justjs.com/posts/npm-link-developing-your-own-npm-modules-without-tears)
The question:
Assume a developer has now finished making changes to both Project A and the custom npm package. Here are the next steps:
He or she must submit a Pull Request for the custom package and wait for it to be code reviewed and merged.
He or she must now open Pull Request for Project A, containing a bumped version number on the custom package in package.json.
This feels clunky and prone to blocking our other developers.
Does anyone have suggestions for a better workflow when building a custom npm package and a project that depends on it at the same time?

What I do is use username/repo#branch as the version in package.json. This causes npm to pull directly from my fork on GitHub, bypassing the npm registry. I tend to only do this when I cannot wait for the maintainer to publish a release to the npm registry (not that often for me).
When the maintainer publishes a release to npm then I update the version number to the new release. Also, I would not include the version number in a pull request, I would always let the maintainer(s) decide how to bump the version.

So you have project A depending on package B. First, if B is under rapid development, it does not make much sense to make A dependent on B (by listing it in package.json and 'npm install'-ing it): it'll bring you more pain than gain. Instead of this, copy B directly into the A and use it directly (without using any npm machinery).
Only when B's API gets stable enough, publish it as a separate module and depend on it npm way.
But this is not all! To keep things reasonably separated and decoupled, you should use git submodules.
https://git-scm.com/book/en/v2/Git-Tools-Submodules
This great feature of git allows you to put one git repo inside another git repo. This way, both of your projects are reasonably well decoupled; also this makes the process of publishing B as a separate unit much easier.
I've tried both approaches ( a) npm with git branch dependency vs. b) git submodules, no npm) on two separate middle-sized projects and I enjoyed the submodules way much more :)

I think one possible solution is to be more generic with the versioning in Project A's package.json.
Instead of explicitly maintaining the version number of the custom npm module dependency, we can use asterisks in the semvar statements.
Eg:
"#org/custom-node-module": "0.1.2" - requires manually changing everytime the npm package is updated.
"#org/custom-node-module": "0.*.*" - running npm install will always grab the most recent non-breaking version.