We Keep Coding

When I modify a node module in my vue.js project, do I have to recompile something to get it to work? The change is not reflected

I'm working on a Vue.js project and I run into something the Bootstrap-vue module does that I'd like to get rid of. I located the place in the module that causes the behavior and commented it out. However, this is not reflected on the project. Did I miss a step here?

Firstly, never a good idea to alter your node_modules packages directly,
if you want to see the changes then run yarn install or npm install depending on what package your project is running on, after that run your local serve and changes should have taken effect
Side note: if you are working within a team or peer programming then I would not advise the altering of your node_modules, as the package.json would just overwrite the the changes on their side if using a Git environment to share code

Assertion Error : App Version has already been registered

Im using ember to develop a project.
Please help me with this error. Im unable to run my project on local. After hitting
ember server the build is successful. But on hitting the http://localhost:4200
Loads empty page with console error.
Uncaught Error: Assertion Failed: The initializer 'App Version' has already been registered
at assert (index.js:172)
at Function.initializer (index.js:420)
at registerInitializers (index.js:27)
at loadInitializers (index.js:68)
at Module.callback (app.js:25)
at Module.exports (loader.js:106)
at requireModule (loader.js:27)
at app-boot.js:3
Unable to understand what to do. Any help regarding this would be appreciated.

I did a code search to see where that initializer might exist and it looks to be part of ember-cli-app-version.
In your place I would remove ember-cli-app-version from your app with npm uninstall --save-dev ember-cli-app-version and then run ember serve again. The purpose of this addon is to make it easy to see your app's version number in the ember inspector, but that's not a big deal so removing it won't break anything and should get you moving forward.
If you want to investigate the issue further try searching your code base (including node_modules) for App Version to see where a duplicate exists.

Running npm install solved the problem.

The actual issue was due to the iCloud sync being active in my Macbook.
Turning iCloud sync off should solve the problem.

Cannot load linked modules from npm/yarn link in WSL

I'm running into a really strange issue when trying to import a local dependency into my project.
I have a project called 'test_project' and another project that will be linked called 'test_module'. I link test module to the global node_modules folder (I've tried npm link and yarn link). Then in test_project I link test_module. I import test_module into the index.js file, but when I do a yarn/npm start I get this error:
Failed to compile.
./src/index.js
Cannot find file: 'index.js' does not match the corresponding name on disk: '/mnt/c/users/<my_username>/Projects/test_module/Users'.
For whatever reason '/Users' is getting added to the end of the path and I have no idea why. I've blown away my environment twice now and it keeps happening. Is this an issue with WSL? Do I have something configured wrong?
EDIT: 'test_project' was generated from create-react-app, with no modifications. In case you wanted to know how my environment is setup.
EDIT2: I tried this in Window's CMD, and everything worked properly. So it seems like the issues is caused by a combination of WSL, my node installation, and whatever the hell else :/
Thanks

I figured out how to resolve the issue. You need to edit your wsl config and set the root to '/'. My theory is somewhere a relative path is being used, and using '/' as the root removes '/mnt/' from the path, allowing it to step back properly. However, I can't back it up with facts :D
Anyway, the fix is easy.
sudo vim /etc/wsl.conf
Then add this field so the file looks like this:
[automount]
root = /
options = "metadata"
(I have the options field there to resolve permission issues)
Then fully logout/signout, log back in, unlink the module, blow away the node_modules folder, run npm install, and then re-link. It should all work at that point.
Cheers!

This issue had been driving me nuts for a long time but I was able to solve it for the project I'm working on. (Remounting the WSL root didn't fix the issue for me unfortunately.) The symptoms are slightly different from the ones in the original question but I'm hoping what I found might at least provide some insight.
For me, the issue was a combination of factors. It occurred whenever I tried to run react-scripts start for a certain project. The odd part was that I had another project in the WSL with a nearly identical setup that ran fine.
After some hacking, I narrowed the issue down to the case-sensitive-paths-webpack-plugin that react-scripts was using internally. By dropping a bunch of console.log() statements in the fileExistsWithCase method, I was able to pinpoint the cause of the issue.
The method confirms whether a file/directory exists on disk with casing that matches the passed string (filepath). In order to do this, it recursively checks each directory in the path. Unfortunately the error logging appears to be a bit broken because, when an error bubbles up through the recursion loops, it appends the name of the folder in error as if it were the original filename (reported this as an issue in the create-react-app repo).
For example, the error from the original question was
Cannot find file: 'index.js' does not match the corresponding name on disk: '/mnt/c/users/<my_username>/Projects/test_module/Users'.
In this case, after recursing a few times, the library listed everything in /mnt/c and, seeing that the users directory did not exist but the Users directory did, the error bubbled up and was incorrectly reported with a bad file of /mnt/c/users/<my_username>/Projects/test_module/Users.
Now, when checking each file/directory, the library first checks its cache. And ahead of time it primes the cache with the current working directory. This was ultimately why one of my projects worked but the other didn't. The project that worked was using npm so the node_modules were of the form $PWD/node_modules/foo which would stop recursing once $PWD was reached. The other project, however, was using pnpm and the failing dependencies were hoisted up to a higher directory. In my case, those dependencies failed whenever it tried to validate a directory on my system called /mnt/c/Users/[username]/wslhome, which it saw as WSLHome on disk.
I was lucky enough to just be able to rename WSLHome to wslhome to get things working for my project. Unfortunately /mnt/c/Users wouldn't be as easily renamed since it's created by Windows.
Overall, it looks like the issue largely hinges on how the absolute paths of the package's dependencies are defined and whether the casing matches what Node's path sees.
UPDATE: When I went to use the project today it started failing again, this time complaining about the "Users" directory having improper casing. -_- So it appears that the issue may be somewhat inconsistent. I came upon an article about updating case sensitivity options when using Windows directories and, after adding case=dir to my wsl.conf options and restarting the subsystem, the error disappeared. Given its inconsistent nature, however, I can't say for certain whether that was the solution.
One additional observation that's potentially related is that discrepancies seem to be visible when running readlink -f against a dependency directory. Sometimes the results have the proper casing and sometimes they do not. (For example, right now, readlink -f ~/dev improperly returns a subdirectory of /mnt/c/users whereas readlink -f . correctly returns a subdirectory of /mnt/c/Users while in the ~/dev directory.)

Linked npm library not updating locally

I have the following library https://github.com/codyc4321/react-data-components-updated
I installed it in my react project locally like npm i ~/react-data-components-updated
Now running my node server I don't get any changes no matter what I do. I am seeing old print statements which I deleted, and my new ones are not coming:
console.log('data in dataSort() in dataReducer.js:');
console.log(state.data);
doesn't show up.
I have constantly reinstalled like $ npm i ~/react-data-components-updated/ and it isn't helping. I was seeing weird errors affecting this location:
http://localhost:3001/__webpack_hmr
but right now I get a 200 for that address and it still isn't updating. How can I use this library locally and have my project update when it sees changes?

Problem is that your package got installed and is now in your-project-folder/node_modules, so in order for the modifications to replicate you have four options:
Directly modify the scripts in your-project-folder/node_modules/react-data-components-updated [not recommended]
Delete your-project-folder/node_modules/react-data-components-updated and run npm i ~/react-data-components-updated
Runnpm uninstall react-data-components-updated && npm i ~/react-data-components-updated so it reinstalls with the current files.
Go to ~/react-data-components-updated/package.json and upgrade the version manually (or by CLI) and then running npm update in your project.
Depending on your needs and how you're handling changes in your local package, one may be better than the other.

Exception in defer callback: Error: No uiManager configured on Router

I guess the better question here is more general: how do I debug errors for deployed apps? Does Meteor have commands/logs I can look at? I'm really not sure where to begin because everything works fine locally.
I'm getting this error in the browser console when I try to view the Meteor app I deployed to *.meteor.com. Output is a blank screen, but locally, the same code results in no errors and output is normal.
Has anyone seen this before? There's a thread connecting this to accounts-ui-bootstrap-3 but I'm not using that.
For reference, I'm using Meteor 0.8.1.3, blaze-layout 0.2.4, iron-router 0.7.1, and accounts-entry 0.7.3.
EDIT: looking at meteor logs right now but nothing constructive so far.

Same issue, in same places (prod but not dev). Running mrt update and meteor update fixed it for me.

Are you using meteorite? Try adding blaze-layout:
mrt add blaze-layout
And check in .meteor/packages that it loads after iron-router.
Then deploy as usual to *.meteor.com

I encountered this issue after updating to the latest meteor with:
$ sudo meteor update
Read through several posts, and found my issue was caused by not running the update through Meteorite:
$ sudo mrt update
This fixed the slew of errors I encountered.
Also, I had to remove the package blaze-layout, which I had manually added through mrt as suggested above, because it caused a recursive dependency with with iron-layout.