I am using webpack with react and module federation and share components between. But one of the dependency packages gives warning/error such as:
"Compiled with problems:X
WARNING in shared module luxon -> /Users/Desktop/settings_test/react-webpack-typescript-starter/node_modules/luxon/src/luxon.js
No version specified and unable to automatically determine one. No version in description file (usually package.json). Add version to description file /Users/skenariolabs/Desktop/settings_test/react-webpack-typescript-starter/node_modules/luxon/src/package.json, or manually specify version in shared config."
My webpack setup looks like this:
shared: {
...deps,
'luxon': {
singleton: true,
requiredVersion: deps['luxon'],
},
}
But it still does not work. Ive tried with different versions same issue. Also tried to delete luxon from node_modules and cleared node cache but the warning is coming. Is there atleast possibility to hide this warning message?
The topic is old, but this worked for me:
luxon: {
version: '^3.2.1',
singleton: true,
eager: true,
},
Maybe it will help someone :)
Related
I am trying to learn Gatsby and I included prettier-eslint plugin with a common configuration. You can see my configuration, the files, etc
When I try to add a css file I get this error:
Have you tried using the following?
eslint: {
patterns: "**/*.{js,jsx,ts,tsx}",
customOptions: {
fix: true,
cache: true,
},
},
The eslint pattern seems to be a string, not an array according to the plugin's example.
This seems to be an unresolved issue of the plugin, according to this opened issue (from a week ago), so keep an eye on that stack trace to see how it evolves. If the dependency has a bug when using the defaults (and suggested) configuration, there's nothing you can do except making a PR if you are able to spot the bug in the source code or wait for the resolution.
I had the same issue. Turns out you must have a prettier config (.prettierrc or similar) set up. Check to make sure you have a config as mentioned in the Prettier docs.
I'm using the next npm package which already requires the prop-types library. prop-types works as expected when I import it.
The problem is ESLint is telling me "'prop-types' should be listed in the project's dependencies". I've attempted to set the ESLint rule:
"rules": {
"react/prop-types": "off",
},
also
"rules": {
...
"import/no-extraneous-dependencies": [
"error", {
"devDependencies": true,
"optionalDependencies": true,
"peerDependencies": true,
"bundledDependencies": true
}
]
}
However, the ESLint error is still being detected. I don't want to add prop-types to my package.json because it's already included with next. I've seen that these attempts have worked for React.js apps, but it does seem to be working for my Next.js app. Is there anyone that could shed more light on this issue I'm having?
It doesn't matter which package is having which dependency, if you're directly using a package, it is recommended that it should be your dependency too. I'm not one of the developers of eslint-plugin-import, but the inspiration behind the rule would probably have been somewhat like this:
It may happen that a package foo may stop bundling a certain package bar with it, or maybe foo changes bar's version. But since which packages a package internally use don't affect semantic versioning until the exposed methods and behavior are the same, you may not even get a major version update. This means that you'll still have "foo": "^a.b.c" in your package.json, but bar will be updated. And if you are using bar without explicitly specifying it in your dependencies, you're are left with a code that may not work as intended, or may not work at all.
Now coming to your problem, you need to disable import/no-extraneous-dependencies to ignore that (linter) warning/error. To do that you can refer the docs: Disabling Rules with Inline Comments and Configuring Rules. However, the simplest method will be to keep using the rule, and just ignoring it for a line:
// eslint-disable-next-line import/no-extraneous-dependencies
import PropTypes from 'prop-types';
I'm developing a project in React Native. I've finished the coding and after this, I have to install some dependencies such as react-native-screens, react-native-vector-icons, etc.
It appears to me: "Unable to resolve module ./InitialWindowSafeAreaInsets from node_modules\\react-native-safe-area-context\\src\\index.tsx. Below there is what appear in the Metro Bundler of my localhost:
LOGGED IN AS
INFO
16:02
Starting Metro Bundler on port 19001.
INFO
16:02
Tunnel ready.
ERROR
16:03
Unable to resolve "./InitialWindowSafeAreaInsets" from "node_modules\react-native-safe-area-context\src\index.tsx"
ERROR
16:03
Building JavaScript bundle: error
I know that I could simply install react-native-safe-area-context, but due the fact I haven't found any issue about this neither here nor in GitHub, I've preferred to be conservative and share with you the issue, instead of install the package and it becomes a snowball.
Maybe the solution is really install react-native-safe-area-context package, but I prefer to share before, because maybe anyone is being the same issue and could help with further information.
Later, I installed the react-native-safe-area-context package, and it remains the same error. How could I solve this issue?
This problem occurs with the following combinations:
expo#3.13.1
react-native-safe-area-context#0.6.0
Expo asks for react-native-safe-area-context#0.6.0, but please ignore it.
Actually, you need #0.7.3.
(Expo send 'InitialWindowSafeAreaInsets', but #0.6.0 cannot receive it. #0.6.0 can only receive 'InitialSafeAreaInsets'. Who Moved My 'Window'?)
so, please try this way.
yarn add react-native-safe-area-context#0.7.3
For some people met the issue must to change resolver in metro config file to have
'ts' extension ...
module.exports = {
resolver: {
/* resolver options */
sourceExts: ['jsx','js','tsx', 'ts'] //add here
},
transformer: {
getTransformOptions: async () => ({
transform: {
experimentalImportSupport: false,
inlineRequires: false,
},
}),
},
};
Basically I am getting this list of errors after installing react-awesome-query-builder package on a brand new installed Gatsby environment.
The examples to this solution, point to add some configuration to the webpack.config.js, but on Gatsby not sure where I can add the fixes. If someone can point me to the right direction.
While there is a way to add custom webpack config settings in Gatsby, this issue might be solvable by adding Gatsby packages for less and ant design (gatsby-plugin-antd, and gatsby-plugin-less).
npm install --save antd gatsby-plugin-antd less gatsby-plugin-less
You will also need to add them into your gatsby-config.js file:
plugins: [
{
resolve: "gatsby-plugin-antd",
options: {
style: true,
},
},
{
resolve: "gatsby-plugin-less",
options: {
javascriptEnabled: true,
},
}
]
Each of them have additional configurations you can add in. For gatsby-plugin-antd, you'll want style set to true since it is using less.
For the gatsby-plugin-less package, the options will pass through to less-loader configuration. It seemed like JS being enabled was needed for react-awesome-query-builder to run, which is deprecated. I'm not sure if there is a way to avoid having that on.
I think that should get you past that specific webpack error, I'm not sure if it will make the react-awesome-query-builder demo/example work though.
If you do end up needing to edit the webpack config, you can follow the guide on gatsby's docs.
I know that console.log() will affect react native's pref under release mode, this is stated very clear in the docs, but what about console.debug() and console.warn()?
Otherwise what's the best way to print debug message and not having to take all of them out every time we go into release? Since we will need these message in dev mode again.
If you check the documentation, there are some instructions on how to use the babel plugin to automatically remove all the console.* calls in the release builds.
According to it [1], you just need to install the plugin:
1)
npm i babel-plugin-transform-remove-console --save
2) Add this in your .babelrc file:
{
"env": {
"production": {
"plugins": ["transform-remove-console"]
}
}
}
1 - https://facebook.github.io/react-native/docs/performance.html#using-console-log-statements
There are webpack plugins that are designed to remove specific types of console statements, depending on how you configure them, so that you can, for example, remove only console.debug statements but the last time I tried, I didn't have much luck.
If you are building a React JS app with a recent version of React, for example 15.x, that was created with create-react-app and you eject it with npm run eject, you'll have two separate webpack configurations. You can modify the production configuration (/config/webpack.config.prod.js) and remove all console statement from your production build by modifying the existing UglifyJsPlugin configuration in the plugins section so that it looks something like this:
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false,
// Disabled because of an issue with Uglify breaking seemingly valid code:
// https://github.com/facebookincubator/create-react-app/issues/2376
// Pending further investigation:
// https://github.com/mishoo/UglifyJS2/issues/2011
comparisons: false,
// Drop console statements
drop_console: true, // <--- ADD THIS
},
output: {
comments: false,
},
sourceMap: true,
}),
That's all you should need to do... but again, this will remove all console statements, not just console.debug