Sentry is working properly in debug mode and but when I make a release APK and run it it doesn't give proper information like it gave in debug APK. and I cant identify any issue with the code . if anyone knows about this issue please help.
Minified Names in Production
When bundling for production, React Native will minify class and function names to reduce the bundle size. This means that you won't get the full original component names in your Touch Event breadcrumbs or Profiler spans.
A way to work around this is to set the displayName on all the components you want to track with touch events or to pass the name prop to the Profiler components. However, you can also configure Metro bundler to not minify function names by setting these options in metro.config.js:
module.exports = {
transformer: {
minifierConfig: {
keep_classnames: true, // Preserve class names
keep_fnames: true, // Preserve function names
mangle: {
keep_classnames: true, // Preserve class names
keep_fnames: true, // Preserve function names
},
},
},
};
Paste the above snippet in your metro.config.js file in react native project
Related
I'm currently building a UI Kit for a client who is using ASP.NET for the main application/backend for their project. The UI Kit that I'm building is created using NuxtJS and I want to compile all of the SCSS files along with Bootstrap into a single compiled CSS file, from what I've gathered on the Nuxt Docs they recommend compiling the SCSS files into single CSS files for each component.
Before I start making a mess of the config file, is there a way to compile them into a single file so the client can just enqueue it on their end? It doesn't need to be the most performative which is why we're going to push it into a singular file.
Here is the part of the doc for Nuxt2, I quote
You may want to extract all your CSS to a single file. There is a workaround for this:
nuxt.config.js
export default {
build: {
extractCSS: true,
optimization: {
splitChunks: {
cacheGroups: {
styles: {
name: 'styles',
test: /\.(css|vue)$/,
chunks: 'all',
enforce: true
}
}
}
}
}
}
This part is not directly written but still available for Nuxt3, so I guess that it should work in a similar approach.
There is only one discussion on Nuxt3's repo, but you may start trying the snippet above already, to see if it fill some of your needs.
i have been trying to find documentation on this but i havent been able to. I use stylint in a project and we have the css order option activated. I haven't been able to set up VS code to show the errors and i haven't found a page with the information to actually know the order,so i always need to check on compile time if i have any mistakes in the CSS order properties, and it shows a huge error on screen.
this are the stylelint rules we have
module.exports = {
extends: ['stylelint-config-standard', 'stylelint-config-concentric-order'],
rules: {
'at-rule-no-unknown': [
true,
{
ignoreAtRules: ['mixin', 'if', 'else', 'include', 'extend']
}
],
'max-nesting-depth': 4,
indentation: 4,
// add your custom config here
// https://stylelint.io/user-guide/configuration
'selector-pseudo-element-no-unknown': [
true,
{
ignorePseudoElements: ['v-deep']
}
]
}
}
I dont see anything weird about it. It there a page where i can find the correct order? it is so annoying because when i get a stylelint order error, i usually have to find it in a few tries.
You are extending the stylelint-config-concentric-order community config. This config includes and configures the stylelint-order community plugin. You can find the order of the properties in the repo on GitHub.
You can see Stylelint errors in VS Code using the official Stylelint extension.
And you can have the extension automatically fix problems on save, which will include the order of your properties, using the editor.codeActionsOnSave configuration property:
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.stylelint": true
},
"stylelint.validate": ["css", "postcss","scss"],
"css.validate": false,
"scss.validate": false
}
Alternatively, you can run npx stylelint "**/*.scss" --fix" on the command line to automatically fix problems.
I am using Vue.js and have only 4 components in my project.
I imported only bootstrap, jquery and lodash:
import { map } from 'lodash';
import 'bootstrap/js/dist/modal';
import $ from "jquery";
But npm run production creates
bundle of 400kb size.
npm run production is configured as shown below.
cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --no-progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
Is it possible to reduce bundle size to ~100KB ? If yes how?
You should add bundle analyzer to your webpack config.
That tool will help you to understand what is going on with your final bundle for example:
you have imported something accidentally and didn't noticed that
one of your dependencies is really big and you should avoid using it
you accidentally imported whole library when you just wanted to import single function from that library (that is common with lodash)
Here is an example of how you can add bundle analyzer to your webpack config:
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
const isBundleAnalyze = true; // turn it too true only when you want to analyze your bundle, should be false by default
module.exports = {
// ... rest webpack config here
plugins: [
// ... rest webpack plugins here
...isBundleAnalyze ? [ new BundleAnalyzerPlugin() ] : []
]
};
Also check your final js file.
It should be a single line of code with simple variables. Something like this: !function(e){function t(t){for(var n,r,o=t[0],i=t[1],s=0,l=[];s<o.length;s++) if it doesn't looks like that it means that you configured your production webpack build incorrectly.
It's pretty obvious why your bundle is over 400kb, you are importing lodash and jquery, you are just missing moment.js (a little joke), but one thing that you can do is use only what you need.
First, if you are using Vue, or React, or any of those jQuery UI libraries you shouldn't be using jQuery unless is necessary.
Another thing that you can do is import only what you need, instead of:
import { map } from 'lodash';
try
import map from 'lodash/map';
or even better
import map from 'lodash.map';
https://www.npmjs.com/package/lodash.map
Lazy imports, read more here. This will allow splitting your bundle into pieces that can be called at execution time, reducing considerably your app size.
const Foo = () => import('./Foo.vue')
There is also SSR (Server Side Rendering), which is basically generating the initial HTML code of your app at build time and rendering outputting that, to show the users that something is on the site, but you also need to understand that, this won't do much, since the browser needs to parse the Javascript code (the hydration process) in order to make the site functional.
If you are using React as of April 2021, the React team announced React Server Components, which seems like a big thing coming up, I supposed that many other libraries will be moving components to the server (and I hope Vue does).
Again as of today don't use it on production.
Other answers mentioned the use of webpack-bundle-analyzer, here is a trick how to use it:
webpack.config.js
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
const analyzing = process.env.NODE_ENV === 'analyze';
module.exports = {
plugin: [
...(analyzing ? [new BundleAnalyzerPlugin()] : [])
]
}
on your package.json
{
"scripts": {
"analyze": "NODE_ENV=analyze webpack build"
}
}
use CompressionWebpackPlugin and try gzip
https://nuxtjs.org/api/configuration-build#babel
I originally left the presets as default.
I then followed the suggestions on
https://github.com/nuxt/nuxt.js/issues/1776
However this dealt more with pipelines
I am just trying to get it to convert the es6 to es5 (import chief among the reasons)
I get the same result or a complete failure no matter if i add the .babelrc, adjust package.json, adjust nuxt.config.js or a combination of them.
currently i have adjusted my nuxt.config.js to:
/*
** Build configuration
*/
build: {
babel: {
presets: ['#babel/preset-env'],
configFile: false,
babelrc: false,
plugins: ['#babel/plugin-syntax-dynamic-import']
}
}
When i upload the entire .nuxt folder to my server (running plesk using phusion passenger)
I get the following error
/var/www/vhosts/website.com/app/client/server.js:1
(function (exports, require, module, __filename, __dirname) { import { stringify } from 'querystring'
My site root is
/var/www/vhosts/website.com/app/client/
The first line of server.js
import { stringify } from 'querystring
Changing this to
var stringify = require("querystring").stringify
Eliminates the error however i would need to go through page after page to remove this. My understanding is i can progamically adjust this using babel. But no matter what ive tried the file stays the same.
I did use the Nuxt CLI to automatically set up babel and webpack but using the above build config is not the default. I have attempted to play with it but i get the same result
I added babel/polyfill to try and get around the import issues without any success
I'm trying to move one of my custom elements into a plug-in so that I can re-use it across projects.
I had a look at the skeleton plugin and noticed that it has a src/index.js that returns a config with all custom elements defined as globalResources.
So I tried the same thing and I basically have:
src/index.js
export function configure (config) {
config.globalResources([
'./google-map',
'./google-map-location-picker',
'./google-map-autocomplete'
]);
}
And then I have each one of my custom elements next to index.js, for example:
google-map.js
import {inject, bindable, bindingMode, inlineView} from 'aurelia-framework';
#inlineView(`
<template>
<div class="google-map"></div>
</template>
`)
#inject(Element)
export class GoogleMapCustomElement {
// All the Custom Element code here
}
I've also set up a basic npm script that runs babel on the code and sticks it in dist/:
"main": "dist/index.js",
"babel": {
"sourceMap": true,
"moduleIds": false,
"comments": false,
"compact": false,
"code": true,
"presets": [ "es2015-loose", "stage-1"],
"plugins": [
"syntax-flow",
"transform-decorators-legacy",
"transform-flow-strip-types"
]
},
"scripts": {
"build": "babel src -d dist"
},
Tbh I'm not entirely sure this is all correct but I took some of it from the skeleton plugin and it seems to run fine.
Anyway, the problem I'm having is that after I install the plugin (npm install --save-dev powerbuoy/AureliaGoogleMaps), add it to my aurelia.json in build.bundles[vendor-bundle.js].dependencies and tell aurelia to use it in main.js (.use.plugin('aurelia-google-maps')) I get:
GET http://localhost:9000/node_modules/aurelia-google-maps/dist/index/google-map.js (404)
So my question is, where does it get the dist/index/ part from?? I'm configuring my globalResources in index.js but nowhere does it say that I have an index folder.
What am I doing wrong?
Bonus question: What is the bare minimum required to transpile my ES6 plug-in code so that others can use it? Does my babel configuration look correct?
What about referencing your plugin within aurelia.json, like this:
{
"name": "aurelia-google-maps",
"path": "../node_modules/aurelia-google-maps/dist",
"main": "index"
}
I have absolutely no idea why, but in order to solve this problem I actually had to move my custom elements inside an index/ folder.
So now I have this:
- index.js
- index/
- custom-element-one.js
- custom-element-two.js
And my index.js still looks like this:
export function configure (config) {
config.globalResources([
'./custom-element-one',
'./custom-element-two'
]);
}
Where it gets index/ from I guess I will never know, but this works at least.
I did need the babel plug-in Marton mentioned too, but that alone did not solve the mystery of the made up path.
Edit: To elaborate a bit further, if I name my main entry point something other than index.js the folder too needs that name. For example, if I were to rename index.js main.js I would need to put my globalResources inside a folder called main/.
Update:
Edit: thanks for clarifying why you don't want to use the whole skeleton-plugin package.
Focusing on your original question: aurelia-cli uses RequireJS (AMD format) to load dependencies. Probably, your current output has a different format.
Add transform-es2015-modules-amd to babel.plugins to ensure AMD-style output, so it will be compatible with RequireJS and therefore with aurelia-cli.
"babel": {
"sourceMap": true,
"moduleIds": false,
"comments": false,
"compact": false,
"code": true,
"presets": [ "es2015-loose", "stage-1"],
"plugins": [
"syntax-flow",
"transform-decorators-legacy",
"transform-flow-strip-types",
"transform-es2015-modules-amd"
]
}
Original:
There are several blog post about plugin creation, I started with this: http://patrickwalters.net/making-out-first-plugin/ .
Of course, there have been many changes since then, but it's a useful piece of information and most of it still applies.
I'd recommend using plugin-skeleton as project structure. It provides you with a working set of gulp, babel, multiple output formats out-of-the-box.
With this approach, your plugin's availability wouldn't be limited to JSPM or CLI only but everyone would have the possibility to install it regardless of their build systems.
Migration is fairly easy in your case:
Download skeleton-plugin
Copy your classes + index.js into src/
npm install
...wait for it...
gulp build
check dist/ folder
most of your pain should now be gone :)
Here are some details based on my observations/experience.
1. Main index.js/plugin-name.js:
In general, a main/entry point is required, where the plugin's configure() method is placed. It serves as a starting point when using it within an Aurelia application. This file could have any name, usually it's index.js or plugin-name.js (e.g. aurelia-google-maps.js) to make it clear for other developers what should be included for bundling. Set that same entry point in package.json as well.
In addition to globalResources, you can implement a callback function to allow configuration overrides. That can be called in the application, which will use the plugin. Example solution
Plugin's index.js
export * from './some-element';
export function configure(config, callback) {
// default apiKey
let pluginConfig = Container.instance.get(CustomConfigClass);
pluginConfig.apiKey = '01010101';
// here comes an override
if (callback) {
callback(pluginConfig);
}
...
config.globalResources(
'./some-element'
);
}
Your app's main.js
export function configure(aurelia) {
aurelia.use
.standardConfiguration()
.developmentLogging()
.plugin('aurelia-google-maps', (pluginConfig) => {
// custom apiKey
pluginConfig.apiKey = '12345678';
});
aurelia.start().then(a => a.setRoot());
}
2. HTML and CSS resources:
If you have html only custom elements, you can make them available using globalResources.
Custom css styling is going to require a bit of additional configuration in bundling configuration (see below).
3. Using the plugin with aurelia-cli: Documentation
One of the first new features you'll see soon is a command to help you with 3rd party module configuration. The command will inspect a previously npm-installed package, and make a configuration recommendation to you, automating the process if you desire.
While we are looking forward to that above moment, let's edit aurelia.json:
Configure plugin dependencies. If there are any external libraries (e.g. Bootstrap), then those should be included before your plugin.
Include your plugin:
...
{
"name": "plugin-name",
"path": "../node_modules/plugin-name/dist/amd",
"main": "plugin-name",
"resources": ["**/*.html", "**/*.css"] // if there is any
},
...
Now, your plugin is ready to include it in main.js as showed in Section 1..
I hope you didn't get sick of reading the word 'plugin' so many (21!) times. :D