Symlinking metro.config breaks from Expo SDK 44 to 46. How to symlink in 46? - expo

I started a new mobile app project and since we have our own mobile components for reusability, we also use symlinking from the local component to the Expo app to make sure it's being developed properly. We have successfully linked prior Expo apps using SDK 44, but in this new project, we decided to use the most recent 46. It seems when I update the metro.config file the same as before, the bundler crashes.
default metro.config
const { getDefaultConfig } = require('expo/metro-config');
const path = require('path');
// const workspaceRoot = path.resolve(__dirname, '../myComponentLib'); // this gets uncommented when using a link
const defaultConfig = getDefaultConfig(__dirname);
defaultConfig.transformer.babelTransformerPath = require.resolve(
'react-native-svg-transformer',
);
const assetExts = defaultConfig.resolver.assetExts;
const sourceExts = defaultConfig.resolver.sourceExts;
defaultConfig.resolver = {
assetExts: assetExts.filter((ext) => ext !== 'svg'),
sourceExts: [...sourceExts, 'svg'],
};
defaultConfig.resolver.nodeModulesPaths = [
path.resolve(__dirname, 'node_modules'),
// path.resolve(workspaceRoot, 'packages/mobile/node_modules'), // this gets uncommented when using a link
];
// defaultConfig.watchFolders = [path.resolve(workspaceRoot)]; // this gets uncommented when using a link
module.exports = defaultConfig;
When I use the metro.config like above, it's fine. But if I uncomment the 3 lines notes, it fails. The error I get is:
I am curious, is there a difference in linking between the different SDKs now?

Wow, the reason for this is hidden well inside the docs: https://docs.expo.dev/guides/monorepos/#modify-the-metro-config
Scroll down to the section:
Why do we need to watch all the files with the monorepo?
Their example to watch scoped package names does the trick:
// If your monorepo tooling can give you the list of monorepo workspaces linked
// in your app workspace, you can automate this list instead of hardcoding them.
const monorepoPackages = {
'#acme/api': path.resolve(workspaceRoot, 'packages/api'),
'#acme/components': path.resolve(workspaceRoot, 'packages/components'),
};

Related

GLB/GLTF File Loading with Storybook and Webpack with file-loader

I have a component library I am creating with Storybook that needs access to .glb/.gltf files. Based on research, it seemed like the best thing to do here was to use the file-loader Webpack functionality, and augment the storybook main.js as such:
// .storybook/main.js
module.exports = {
"stories": [
"../src/**/*.stories.mdx",
"../src/**/*.stories.#(js|jsx|ts|tsx)"
],
"addons": [
"#storybook/addon-links",
"#storybook/addon-essentials",
"#storybook/preset-create-react-app"
],
webpackFinal: async (config, { configType }) => {
config.module.rules.push({
test: /\.(glb|gltf)$/,
use: ['file-loader'],
include: path.resolve(__dirname, '../'),
});
return config;
},
};
Then, in my jsx file that references the mesh:
// src/components/MeshLoader.jsx
import MyMeshFile from "./meshes/MyMesh.glb";
import { useGLTF } from "#react-three/drei";
export default function Model(props) {
const group = useRef();
const { nodes, materials } = useGLTF(MyMeshFile);
// Do more stuff with these things
}
When I run compile, everything works, and if I log what MyMeshFile is, I get a path like:
static/media/MyMesh.976a5ad2.glb, as expected.
However, the rest breaks with an error Uncaught Unexpected token e in JSON at position 0, basically on account of the useGLTF function failing at the contents of that file.
It turns out that http://localhost:6006/static/media/MyMesh.976a5ad2.glb is actually a file with the contents of
export default __webpack_public_path__ + "178cb3da7737741d81a5d4f0c2bcc161.glb";
So it seems like there is some redirection happening. If I direct the browser at http://localhost:6006/178cb3da7737741d81a5d4f0c2bcc161.glb, I get the file I want.
My first question, is whether this is the expected behavior here, given the way I have things set up. If so, it seems like I would have to parse the contents of the file path given by Webpack, and use that to get the actual path. That seems to be a bit convoluted, so is there a better way of handling this?
Thanks for the help!
UPDATE:
I have tested with the gltf-webpack-loader loader, by adding the following to the .storybook/main.js file:
...
config.module.rules.push({
test: /\.(gltf)$/, // Removed gltf from file-loader
use: [{loader: "gltf-webpack-loader"}]
})
...
And tried the same thing with a gltf file. I get the same behavior of receiving the "redirect" file instead of the actual one I want.
So it turns out that there is currently a bug with "#storybook/preset-create-react-app" that is causing this issue. Removing that add-on seems to resolve the issue described here, although it does produce a warning that:
Storybook support for Create React App is now a separate preset.
WARN To use the new preset, install `#storybook/preset-create-react-app` and add it to the list of `addons` in your `.storybook/main.js` config file.
WARN The built-in preset has been disabled in Storybook 6.0.

How can i attach a debugger to google v8?

In my application (Windows 10 VC2017) i enabled the possibility to write and execute scripts using google v8 and v8pp.
v8pp calls a script like this:
v8::Local<v8::Value> context::run_script(std::string const& source, std::string const& filename)
{
v8::EscapableHandleScope scope(isolate_);
v8::Local<v8::Context> context = isolate_->GetCurrentContext();
v8::ScriptOrigin origin(to_v8(isolate_, filename));
v8::Local<v8::Script> script;
bool const is_valid = v8::Script::Compile(context,
to_v8(isolate_, source), &origin).ToLocal(&script);
v8::Local<v8::Value> result;
if (!script.IsEmpty())
{
auto res1 = script->Run(context); //
if(! res1.IsEmpty())
result = res1.ToLocalChecked();
}
return scope.Escape(result);
}
How can i attach a debugger (chrome debug) to my code?
I found googles description at https://v8.dev/docs/inspector -
But this leaves some things blank and consists mostly of js code?
And i found the implementation for v8toolkit at https://github.com/xaxxon/v8toolkit/blob/master/src/debugger.cpp. But this seems to run not for windows.
What is a easy way to attach chrome debug to js code? The code is typically not a file but rather is stored in a data base and then stored in a std::string.
I finally got done a windows version of v8inspector that works well with my stand alone windows application with integrated v8.
I made a own fork including descriptions where to find/build the required 3rd party libraries (or where to find prebuilds). I also did a number of changes/additions:
https://github.com/StefanWoe/v8inspector
In the meanwhile this has also been merged into the parent project:
https://github.com/hsharsha/v8inspector
EDIT:
In the meanwhile ive been pointed to another implementation built with boost::beast and no other dependencies. Much simpler and more robust etc.:
https://github.com/ahmadov/v8_inspector_example

Draw.io -- Is there non-minified source?

We are trying to use the latest Draw.io repository, and modify the javascript client side code to change some of its behaviors for an improved UX. But, the only up to date source we can find is here:
https://github.com/jgraph/draw.io/tree/master/war/js
You'll notice that several of the source files are already minified, such as app.min.js
We found an old non-minified version of draw.io from 5 years ago:
https://github.com/vmassol/draw.io
But it looks like it's missing a lot of functionality..
Does anyone have more information about this? Is there a way to get the non-minified source of the up to date version? Just how much functionality is missing from the old version? Or, do we misunderstand something, and the minified files, like app.min.js are just pre-built products from the source that's in the rest of the directories?
Thanks!
The minified and non-minified (NM) sources are both in the project. The NM sources mostly live in the diagramly folder (the old name for draw.io) and the GraphEditor folder.
If you look in the build file, you can see which sources go into which *.min.js files.
The GraphEditor source serve as the base stack under draw.io. It used to be maintained as a cut-down editor, just not any longer.
i managed to run the app from the unminified modifying the index.html as follows:
// Changes paths for local development environment
if (urlParams['dev'] == '1') {
// Used to request grapheditor/mxgraph sources in dev mode
//the line below was: var mxDevUrl = document.location.protocol + '//devhost.jgraph.com/mxgraph2';
var mxDevUrl = document.location.origin + '/mxgraph';
// Used to request draw.io sources in dev mode
//the line below was : var drawDevUrl = document.location.protocol + '//devhost.jgraph.com/drawio/src/main/webapp/';
var drawDevUrl = document.location.origin + '/drawio/src/main/webapp/';
...
//The line below was: var geBasePath = mxDevUrl + '/javascript/examples/grapheditor/www/js';
var geBasePath = drawDevUrl + '/js/mxgraph';
var mxBasePath = mxDevUrl + '/javascript/src';
...
}
To make everything work I had to start an http-server (es. nodejs http-server module) at mxgraph and drawio repos parent.

Including specific style sheets or javascript in ember-cli-build

The problem
I am working on an Ember.js project which has different versions (products) for different clients. Though the functionality is more or less the same, the styling of each product differs big time. Hence we have "default" and product specific style sheets. I have been asked to modify the build code so that only the corresponding .css (.less) files are compiled into the final app.
Originally I was looking at this issue from the wrong side: I tried to exclude the folders containing the unnecessary files with little success. Only then did I realize that it makes more sense not to include the product specific files by default and add them to the tree during the build.
The solution
After changing my point of view I found out there is another way around. I changed the style sheets so that all the "default looks" went into an import-base.less and I created an import-[name_of_product].less for each of the products, with the latters containing the import statement to the default looks, so I only have one file to build. Using the outputPaths option in EmberApp and assuming that the name of the product is stored in the process environmental variable called FLAVOUR my code looks as follows.
// ember-cli-build.js
/* global require, module */
var EmberApp = require('ember-cli/lib/broccoli/ember-app');
module.exports = function(defaults) {
// y u do dis
const options = { outputPaths: { app: { css: { app: false } } } };
const lessFileName = 'import-' + process.env.FLAVOUR.toLowerCase();
options.outputPaths.app.css[lessFileName] = 'assets/application.css'
const app = new EmberApp(defaults, options);
return app.toTree();
};
There is always something
The only problem with that code is that it still needs an app.less and that line of code or else the build fails, couldn't (haven't had time to) figure out a solution.
I also have to mention that the above solution doesn't resolve the original problem, which was:
How to exclude specific files from the working directory before using app.toTree() so that they wouldn't increase file size unnecessarily. Lux was so kind and pointed out that probably in-repo-addons are to be used for such purposes. Yet again, haven't had time to check. :(
I think you can just use funnel!
something like this:
return new Funnel(app.toTree(), {
include: ['**/*']
exclude: ['styles/*.css']
});
general you can do anything you can do in a Brocfile in your ember-cli-build.js!

Getting Interface Implementation of built-in Mozilla Firefox Component

I'm currently trying to develop a custom password manager in c++.
I've already developed a deployable module implementing the nsILoginManagerStorage interface, can install it on firefox and it is being called properly by firefox when a password field appears.
The problem is that when I try to instantiate the nsILoginInfo objects to be returned, the do_CreateInstance function is always returning null.
My method implementation is:
NS_IMETHODIMP FirefoxComponent::FindLogins(uint32_t *count, const nsAString & aHostname, const nsAString & aActionURL, const nsAString & aHttpRealm, nsILoginInfo * **logins)
{
nsILoginInfo ** array = static_cast<nsILoginInfo**>(nsMemory::Alloc(sizeof(nsILoginInfo*)));
nsresult result;
nsCOMPtr<nsILoginInfo> loginInfo = do_CreateInstance("#mozilla.org/login-manager/loginInfo;1" , &result);
//nsCOMPtr<nsILoginManager> loginInfo = do_CreateInstance("#mozilla.org/login-manager;1" , &result);
if (NS_FAILED(result)){
printf("shouldn't be here!!\n");
return result;
}
}
I've tried getting an nsILoginManager instance (just to check if it worked) but it had the same result. The nsILoginInfo can be instantited by java script on firefox using:
Components.classes["#mozilla.org/loginmanager/loginInfo;1"].createInstance(Components.interfaces.nsILoginInfo);
I'm using firefox 20.0 and xul-runner-sdk 20.0 (same results with 20.0.1), on Ubuntu x64, and building with QtCreator (for x64).
My code has been inspired from https://github.com/infinity0/mozilla-gnome-keyring
Since I now that nsILoginInfo is properly loaded into firefox, is there any required field/information for firefox to allow me to access these interfaces?
Thanks for the support.
edit:
Tried to load the module by accessing the component manager directly, but I cannot load the component manager.
nsIComponentManager * manager;
result = NS_GetComponentManager(&manager);
if (NS_FAILED(result)){
printf("failed getting component manager!!\n");
return result;
}
After lots of trial and error I discovered that this error was due to bad linking of the libraries. I was missing one library (libxpcom.so).
To compile and run it right i use the libraries libxpcom.so and libxpcomglue_s.a, both found at the gecko sdk/xul-runner lib folder.
More information about which libraries to compile with in each platform:
https://developer.mozilla.org/en-US/docs/XPCOM_Glue