I have recently tried running a React Native app that is in development on a machine connected to a VPN. The Metro bundler fails to start:
I have tried to specify a local host by starting the project with react-native start --host=0.0.0.0, the result is the following error:
┌──────────────────────────────────────────────────────────────────────────────┐
│ │
│ Running Metro Bundler on port 8081. │
│ │
│ Keep Metro running while developing on any JS projects. Feel free to │
│ close this tab and run your own Metro instance if you prefer. │
│ │
│ https://github.com/facebook/react-native │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
events.js:183
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE 0.0.0.0:8081
at Server.setupListenHandle [as _listen2] (net.js:1360:14)
at listenInCluster (net.js:1401:12)
at doListen (net.js:1510:7)
at _combinedTickCallback (internal/process/next_tick.js:142:11)
at process._tickCallback (internal/process/next_tick.js:181:9)
If I enter http://0.0.0.0:8081 in my web browser, I get a page that says:
React Native packager is running.
If I disable the VPN, everything starts happily...but I'd prefer to not need to disable the VPN when an app needs to be launched. Am I using a command wrong or are the VPN settings that need to be changed?
I am on MacOS 10.14.3
VPN is PIA using their app, but this has happened using TunnelBlick with OpenVPN as well.
Related
I have created a Storybook and after when I change something and save it, the browser does not refresh automatically. So every time I have to press the F5 button. Unfortunately, I could not figure the problem.
I start the storybook with:
yarn storybook
The repository is hosted on https://github.com/softshipper/react-storybook.
Update
I have figured out that on Firefox hot reload works like a charm. However, on Chromium hot reload does not work at all. I am using https://pop.system76.com/ as OS and Chromium is installed with flatpak.
When I start the storybook, in the terminal it shows me:
$ start-storybook -p 6006
info #storybook/react v6.2.7
info
info => Loading presets
info => Loading 1 config file in "/home/developer/projects/openidea/webapp/components/.storybook"
info => Loading 7 other files in "/home/developer/projects/openidea/webapp/components/.storybook"
info => Adding stories defined in "/home/developer/projects/openidea/webapp/components/.storybook/main.js"
WARN unable to find package.json for #rollup/plugin-node-resolve
WARN unable to find package.json for rollup
info => Using prebuilt manager
info => Using implicit CSS loaders
WARN unable to find package.json for #rollup/plugin-node-resolve
WARN unable to find package.json for rollup
info => Using React fast refresh
info => Using default Webpack4 setup
(node:145138) DeprecationWarning: Default PostCSS plugins are deprecated. When switching to '#storybook/addon-postcss',
you will need to add your own plugins, such as 'postcss-flexbugs-fixes' and 'autoprefixer'.
See https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#deprecated-default-postcss-plugins for details.
(Use `node --trace-deprecation ...` to show where the warning was created)
10% building 6/12 modules 6 active /home/developer/projects/openidea/webapp/components/node_modules/babel-loader/lib/index.js??ref--4-0!/home/developer/projects/openidea/webapp/components/.storybook/generated-stories-entry.jsinfo => Using cached manager
webpack built preview 6002361e38573b1c5351 in 9449ms
╭─────────────────────────────────────────────────────╮
│ │
│ Storybook 6.2.7 started │
│ 9.74 s for preview │
│ │
│ Local: http://localhost:6006/ │
│ On your network: http://192.168.178.27:6006/ │
│ │
╰─────────────────────────────────────────────────────╯
webpack building...
webpack built preview 533a9b622317ca763dd0 in 1930ms
I am using Github Actions to run CI and CD for my NextJS app (v9.4.4).
I currently have a jsconfig.json file as the following:
{
"compilerOptions": {
"baseUrl": "src"
}
}
This is great as I can do import Nav from "components/Nav" in lieu of import Nav from "src/components/Nav" and is working perfectly locally (with either next dev or next build).
However, when I try to build the NextJS app on Github Actions, it errors with:
./src/App/index.jsx
Module not found: Can't resolve 'contexts/firebase' in '/home/runner/work/MyFirebaseApp/MyFirebaseApp/src/App'
For context, a sample of my file structure is:
MyFirebaseApp
│ .github
│ next.config.js
│ jsconfig.json
│ ...more config files...
│
└───src
│ │
│ └───App
│ │ │ index.jsx
│ │
│ └───components
│ │ Nav.jsx
│ │
│ └───contexts
│ │ firebase.jsx
I have tried changing the baseUrl to home/runner/work/MyFirebaseApp/MyFirebaseApp/src without any luck.
Is there special webpack configuration or changes I need to make for this to build on Github Actions?
I want to test a camel-component, written by a colleague and me. It runs on Karaf and the following camel bundles are deployed:
80 │ Active │ 50 │ 2.17.1 │ camel-blueprint
81 │ Active │ 50 │ 2.17.1 │ camel-catalog
82 │ Active │ 50 │ 2.17.1 │ camel-core
The component and a blueprint that uses the component is deployed, too. I think that I missed to install a camel feature, which provides the class DefaultComponent, so I think it's not necessary to review the code.
I get the following error:
java.lang.NoClassDefFoundError: org/apache/camel/impl/DefaultComponent
My mistake was that I did not set up the Maven project of the Camel component correctly. To avoid this you can start the development of a Camel component with an archetype.
So you could start like this:
mvn archetype:generate -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-component -DarchetypeVersion=2.24.2
My react native app takes 2 full minutes to load and I'm wondering what's the hold up. When it gets to 97.4% it just freezes for about two full minutes before going to 100%. How can I find out the reason for this delay?
>npm start -- --reset-cache
> crew_rn#0.0.1 start /Users/######/crew_rn
> node node_modules/react-native/local-cli/cli.js start "--reset-cache"
Scanning folders for symlinks in /Users/######/crew_rn/node_modules (9ms)
┌──────────────────────────────────────────────────────────────────────────────┐
│ │
│ Running Metro Bundler on port 8081. │
│ │
│ Keep Metro running while developing on any JS projects. Feel free to │
│ close this tab and run your own Metro instance if you prefer. │
│ │
│ https://github.com/facebook/react-native │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
Looking for JS files in
/Users/#####/crew_rn
Metro Bundler ready.
Loading dependency graph, done.
warning: the transform cache was reset.
BUNDLE [ios, dev] ./index.js ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░ 97.4% (598/606)
I see no one has answered my question and there is interest so I'll just share what I did.
In the package.json file - there were several dependencies. I took out all the dependencies and slowly put them back in until I identified the dependency which was causing the slowdown - and then I changed its version. This is the approach I took.
I'm trying to use the new Google plugin in maven for GAE.
All is running smoothly, unlike with the old plugin.
All but the deploy.
The first alarming thing is that starting from an empty .m2 (I deleted it to be sure that no old versions were messing with me) and during the initial download phase of mvn appengine:update, maven says
Downloaded: http://repo.maven.apache.org/maven2/com/google/appengine/appengine-tools-sdk/1.7.4/appengine-tools-sdk-1.7.4.jar (16762 KB at 788.5 KB/sec)
Then, if I run mvn appengine:update, it says
[INFO] Updating Google App Engine Application
********************************************************
There is a new version of the SDK available.
-----------
Latest SDK:
Release: 1.7.5
Timestamp: Fri Jan 11 00:56:53 CET 2013
API versions: [1.0]
-----------
Your SDK:
Release: 1.7.4
Timestamp: Tue Dec 11 12:41:31 CET 2012
API versions: [1.0]
-----------
When I check my .m2 folder, I got
mog#becca:~/.m2/repository/com/google$ tree -L 2 appengine/
appengine/
├── appengine
│ ├── 1.7.4
│ └── 1.7.5
├── appengine-api-1.0-sdk
│ └── 1.7.5
├── appengine-api-stubs
│ └── 1.7.5
├── appengine-java-sdk
│ └── 1.7.5
├── appengine-maven-plugin
│ └── 1.7.5
├── appengine-testing
│ └── 1.7.5
└── appengine-tools-sdk
└── 1.7.4
This seems to show that the dependencies o the 1.7.5 plugin are incomplete: some lag behind in 1.7.4. The annoying part is that it seems to prevent me from using the automatic java 7 detection feature of the 1.7.5 plugin, as shown below:
When I use mvn appengine:update, I get a warning:
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning
This warning, and the fact that I get an error 500 when I go to my website which then is explained by the following log:
Failed startup of context com.google.apphosting.utils.jetty.RuntimeAppEngineWebAppContext#15a4523{/,/base/data/home/apps/s~trashnao/1.365599992371450729}
org.mortbay.util.MultiException[java.lang.UnsupportedClassVersionError: fr/univnantes/atal/web/trashnao/Controller : Unsupported major.minor version 51.0, java.lang.UnsupportedClassVersionError: fr/univnantes/atal/web/trashnao/Controller : Unsupported major.minor version 51.0]
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:656)
Lead me to think that the used appengine-tools-sdk-1.7.4 doesn't support yet automatic java 7 detection through the pom.xml file.
As said in this video by the devs themselves, this feature of automatic detection of the java 7 target is available in the 1.7.5 plugin.
Trying the solution given in that question, I get this message instead of the one about the boostrap class:
warning: Supported source version 'RELEASE_6' from annotation processor 'com.google.appengine.tools.compilation.DatastoreCallbacksProcessor' less than -source '1.7'
I'd like any suggestion on how to fix that. Ie, how to make the mvn appengine:update goal use the --java_7 option in its invocations of appcfg (related doc)
I can fix this, if you'd like to file an issue and see progress, feel free to do so here : https://code.google.com/p/appengine-maven-plugin/issues/list and I'll keep it updated.
Edit : Fixed in 1.7.6 and using the enforcer plugin to make sure it doesn't happen again.