After updating to latest stable version of library ngx-masonry 14.0.0 tests failed. They had release yesterday (24.10.2022.) and here is the link to their changelog: https://github.com/wynfred/ngx-masonry/blob/master/CHANGELOG.md
Basically they added Ivy build since they were using ViewEngine on older versions. I suppose that this error is connected to that migration to newer Angular compiler. On project we use Angular version 14.
After running npm i ngx-masonry#14.0.0 update was successful without any vulnerabilities.
In order for me to test it, I run ng test for my Angular application to make sure everything is fine. The failing test is basically the basic one which tests if the component is getting created. The following error was thrown in couple of components that rely on ngx-masonry library: ReferenceError: require is not defined
Since this is quite fresh issue (<24hrs old) probably more developers will run into it when they upgrade version to 14.
Link to the issue opened right now on their GitHub repo: https://github.com/wynfred/ngx-masonry/issues/98
Maybe we are missing something or this could be solved easily. :)
The owner of the library have just released 14.0.1 version which contains the fix. After you run npm i ngx-masonry#14.0.1 everything should be fine. Tests are passing as expected and app compiles successfully.
I've just started to use Dependabot and encountered an issue with one of its alerts. I was looking for an answer how to handle such vulnerabilities, but didn't fine any proper resource. What I can see that it is a dependency of my deps, so it affects package-lock file.
Here is what Dependabot provided:
Dependabot cannot update glob-parent to a non-vulnerable version
The latest possible version that can be installed is 3.1.0 because of the following conflicting dependencies:
eslint#8.8.0 requires glob-parent#^6.0.1
postcss-mixins#6.2.3 requires glob-parent#^3.1.0 via a transitive dependency on fast-glob#2.2.7
The earliest fixed version is 5.1.2.
I don't have glob-parent in my package.json file - it is just the dependency of my other dependencies. What is the attitude to handle such alerts? Should I dismiss it? As far as I know manually changing package-lock is not the way to go.
I am trying to get an app up and running with Vue 2 and everything was fine until I tried using the node-sass and sass-loader packages. I started getting errors and after investigation, it looks like I need to be using webpack 5+ for the latest node-sass package to work. After poking around it looks like when I created the project it defaulted to webpack version 4.46.0.
I updated my vue-cli to the latest version as per the instructions on the official page and then tried re-initializing a new project and still have the same issue. Currently, I have #vue/cli 4.5.12 which looks to be the latest (I think).
I am initializing the app with vue create <app-name> and I am using the default configs. I did find this page which says "migrating from v4" which perhaps implies there might be a higher version of vue-cli but again I followed all the instructions to no avail, so not sure if I am just missing something here.
I am pretty novice in Vue and not sure what additional info I should provide to make this useful, but I've searched all over and for the life of me cannot figure out what is going on.
From what I found out on GitHub, the latest stable version - 4.5.12 - of Vue CLI still uses Webpack 4: https://github.com/vuejs/vue-cli/blob/v4.5.12/package.json .
Considering that, the easiest solution in my opinion would be to just downgrade sass-loader to version 10 with npm install sass-loader#10 for example, as suggested here: https://stackoverflow.com/a/66087132/1505369.
You could try using a beta version of vue-cli, as I tried, by updating both #vue/cli-service and, I believe, all the vue-cli plugins to version 5.0.0-beta.0, with npm install #vue/cli-service#5.0.0-beta.0 #vue/cli-plugin-babel#5.0.0-beta.0 #vue/cli-plugin-eslint#5.0.0-beta.0 #vue/cli-plugin-vuex#5.0.0-beta.0. It should end up installing and using Webpack 5. For me personally though, it hasn't really solved the issue, as the new error occurred:
ERROR TypeError: The 'compilation' argument must be an instance of
Compilation TypeError: The 'compilation' argument must be an instance
of Compilation
// ...
In my project, I am using falcor which happen to have Rxjs as a dependency which has a known problem with webpack.
So far after following what the previous link says everything works fine.
Alongside I am using concurrently as a DevDependency, which has Rxjs as a dependency but with a newer version then falcor, when I compile my scripts with webpack I get an error in the browser:
Uncaught TypeError: Cannot read property 'prototype' of undefined
at inherits.inherits.Rx.internals.inherits
I solved the problem by installing Rx as a dependency in my project with the version used by falcor.
Here I am asking is there any solution with either yarn or npm to solve the problem without adding Rx as a dependency.
Sometimes, when using React libraries, such as react-router, I get this error:
Uncaught TypeError: Cannot read property 'firstChild' of undefined
/~/react-router/~/react/lib/ReactMount.js?:606
How do I fix it?
This error is commonly caused by two versions of React loaded alongside.
For example, if you npm install a package that requires a different React version and puts it into dependencies instead of peerDependencies, it might install a separate React into node_modules/<some library using React>/node_modules/react.
Two different Reacts won't play nicely together (at least yet).
To fix it, just delete node_modules/<some library using React>/node_modules/react.
If you see a library putting React in dependencies instead of peerDependencies, file an issue.
In case anyone has this issue having npm linked two modules depending on react, I found a solution...
Let's say you have Parent depending on React, and Child depending on react. When you do:
cd ../child
npm link
cd ../parent
npm link child
This causes this problem, because parent and child will each load their own instance of React.
The way to fix this is as follows:
cd parent
cd node_modules/react
npm link
cd ../../../child
npm link react
This ensures your parent project supplies the react dependency, even when linked, which is how npm would resolve the dependency when you are unlinked.
Using require('react') and require('React') inconsistently causes this problem as well, even if you only have one version of React.
https://www.npmjs.com/package/gulp-browserify didn't have this problem. Once I stopped using gulp-browserify and switched to watchify+browserify, Uncaught TypeError: Cannot read property 'firstChild' of undefined started happening.
It seems to me peerDependencies is not getting traction. See https://github.com/npm/npm/issues/5080#issuecomment-40545599
I am maintaining react-date-picker (and other react modules), and what I've done until now is to specify the React dependency using the caret, for example ^0.12.0.
Also, when doing a build will all concatenated files, for use outside of the npm ecosystem, I use webpack with
externals: { 'react': 'React'}
which will look for the global var React.
For me, the problem was that I was using a <Link> from react-router inside a <NavItem> from react-bootstrap.
If you are experiencing this crash while server side rendering and none of these answers are the problem, here's the likely culprit:
Doing something async (setTimeout, AJAX, etc.) in componentWillMount. Since componentWillMount is called on the server, this setTimeout/request will still fire. If you setState inside this callback then it'll cause the error above.