Error regarding it exceeds the max of "500KB" Babel - babeljs

This issue was one I never had but it just randomly started after completing my game over a month now.
Whenever I run
npm run webpack --watch ./lib/saviors.js bundle.js
I keep getting
[BABEL] Note: The code generator has deoptimised the styling of "/Users/steven/Desktop/Saviors/bundle.js" as it exceeds the max of "500KB".
and my bundle.js.map continue to increase in size. Can someone tell me the reason for this? I'm confused as it just started randomly. While looking online I noticed people mentioned we needed to have /node_modules/ which I already have. Anyone else found a different solution to this problem?
module: {
loaders: [
{
test: [/\.jsx?$/, /\.js?$/],
exclude: /node_modules/,
loader: 'babel-loader',
query: {
presets: ['es2015']
}
}
]
},
Thank you to those who help and provide some advice.

Related

Product images issue in vue storefornt

I integrated vue store front with magento 2, frontend works fine but product images not display in frontend. It throws error Unable to compile TypeScript:\nsrc/image/action/local/index.ts(27,18): error TS2339: Property 'query' does not exist on type 'Request<any, any, any, any>'. imagemagick is also installed and imgurl in local.json is also defined.
Anyone please know about this why error display.
It is about this.req which is typeof Request from express - it has query property. Please make sure you have yarn.lock from the original repo and reinstall dependencies.
If you are using docker, you might need to add:
- './yarn.lock/var/www/yarn.lock'
To volumes section in the docker-compose.nodejs.yml
i have found a simple solution you can try that
copy all your magento 2 pub/media data in vue-storefront-api/var/magento-folder/pub/media
Or
create a symlink if you are working on localhost
vue-storefront-api/config/local.json
"magento2": {
"imgUrl": "http://magento-domain/pub/media/catalog/product",
"assetPath": "/../var/magento-folder/pub/media",
}
vue-storefront/config/local.json
"images": {
"useExactUrlsNoProxy": false,
"baseUrl": "http://localhost:8080/img/",
"useSpecificImagePaths": false,
"paths": {
"product": "/catalog/product"
},
"productPlaceholder": "/assets/placeholder.jpg"
},
run command in vue-storefront and vue-storefront-api

JPAM Configuration for Apache Drill

I'm trying to configure PLAIN authentification based on JPAM 1.1 and am going crazy since it doesnt work after x times checking my syntax and settings. When I start drill with cluster-id and zk-connect only, it works, but with both options of PLAIN authentification it fails. Since I started with pam4j and tried JPAM later on, I kept JPAM for this post. In general I don't have any preferences. I just want to get it done. I'm running Drill on CentOS in embedded mode.
I've done anything required due to the official documentation:
I downloaded JPAM 1.1, uncompressed it and put libjpam.so into a specific folder (/opt/pamfile/)
I've edited drill-env.sh with:
export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pamfile/"
I edited drill-override.conf with:
drill.exec: {
cluster-id: "drillbits1",
zk.connect: "local",
impersonation: {
enabled: true,
max_chained_user_hops: 3
},
security: {
auth.mechanisms: ["PLAIN"],
},
security.user.auth: {
enabled: true,
packages += "org.apache.drill.exec.rpc.user.security",
impl: "pam",
pam_profiles: [ "sudo", "login" ]
}
}
It throws the subsequent error:
Error: Failure in starting embedded Drillbit: org.apache.drill.exec.exception.DrillbitStartupException: Problem in finding the native library of JPAM (Pluggable Authenticator Module API). Make sure to set Drillbit JVM option 'java.library.path' to point to the directory where the native JPAM exists.:no jpam in java.library.path (state=,code=0)
I've run that *.sh file by hand to make sure that the necessary path is exported since I don't know if Drill is expecting that. The path to libjpam should be know known. I've started Sqlline with sudo et cetera. No chance. Documentation doesn't help. I don't get it why it's so bad and imo incomplete. Sadly there is 0 explanation how to troubleshoot or configure basic user authentification in detail.
Or do I have to do something which is not told but expected? Are there any Prerequsites concerning PLAIN authentification which aren't mentioned by Apache Drill itself?
Try change:
export DRILLBIT_JAVA_OPTS="-Djava.library.path=/opt/pamfile/"
to:
export DRILL_JAVA_OPTS="$DRILL_JAVA_OPTS -Djava.library.path=/opt/pamfile/"
It works for me.

App works locally but not on Heroku (Application Error); Using Nodemon and Webpack

Alright, I've tried to look up my question on StackOverflow but I can't find something that helps me since everything I've tried doesn't have any effect on the result (Application error).
So I'm really stumped because the app works perfectly fine on my localhost, but I can't get it to work on Heroku, it just gives me a Application error so I have no idea what the issue is.
So on my package.JSON file looks like this:
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "nodemon --use_strict index.js",
"bundle": "webpack"
},
And I've already tried to change "nodemon" to "node" and gotten rid of --use_strict and ran it on local host and it still works perfectly fine but the Heroku app still gives me a Application Error.
index.js the only thing that I can think of being bad (changed it and it runs here):
// start the server
app.listen(3000, () => {
console.log('Server is running.');
});
webpack.config.js:
const path = require('path');
module.exports = {
// the entry file for the bundle
entry: path.join(__dirname, '/client/src/app.jsx'),
// the bundle file we will get in the result
output: {
path: path.join(__dirname, '/client/dist/js'),
filename: 'app.js',
},
module: {
// apply loaders to files that meet given conditions
loaders: [{
test: /\.jsx?$/,
include: path.join(__dirname, '/client/src'),
loader: 'babel-loader',
query: {
presets: ["react", "es2015"]
}
}],
},
// start Webpack in a watch mode, so Webpack will rebuild the bundle on changes
watch: true
};
It deployed properly after git push heroku master:
https://c1.staticflickr.com/3/2873/33519283263_3d9a711311_z.jpg
I'm pretty much trying to make this app work on Heroku:
https://vladimirponomarev.com/blog/authentication-in-react-apps-creating-components
I think a possible problem might be that you have to run "run bundle" on one shell and "npm start" in the other shell.
Another thing, this app had a lot of things that were npm installed manually in node_modules, which Heroku does not accept if I try to push it on github and will crash, so I'm thinking that might be an issue as well, though I have no idea how to get around that.
This also uses Express and Mongodb, and I added my mongodb info into the index.json file and ran the application, and it worked perfectly fine and after checking the db, the correct info was also inside it, so it's not that either.
You should use process.env.PORT instead of custom port 3000.
Check that you have a mongodb addon purchased, you can get one for free but for limited spacing!
And use the config vars of that database, if you haven't done that already!

Informative stacktraces with karma+browserify, how?

I have a problem with assertion traces - they are not enough informative.
For an instance assertion fault:
should navigate inside of layout
PhantomJS 2.1.1 (Linux 0.0.0)
1) serialize#http://localhost:9876/base/node_modules/mocha/mocha.js?0491afff0b566ea45cd04c9164a355dba705689e:10776:34
processAssertionError#node_modules/karma-mocha/lib/adapter.js:59:50
node_modules/karma-mocha/lib/adapter.js:129:49
I've tried karma-sourcemap-loader, but it does not affect the output for me.
My config:
frameworks: ['mocha', 'chai', 'source-map-support', 'browserify'],
files: [
'tests/**/*.js'
],
browserify: {
debug: true
},
preprocessors: {
'tests/**/*.js': ['browserify']
},
reporters: ['progress', 'nyan'],
Any ideas ?
It seems like problem related to source-maps support by different browsers, this configuration works just fine with chromium browser, but does not provide readable stack-trace information when i'm testing with phantomjs browser.

Logstash-Forwader 3.1 state file .logstash-forwarder not updating

I am having an issue with Logstash-forwarder 3.1.1 on Centos 6.5 where the state file /.logstash-forwarder is not updating as information is sent to Logstash.
I have found as activity is logged by logstash-forwarder the corresponding offset is not recorded in /.logstash-forwarder 'logrotate' file. The ./logstash-forwarder file is being recreated each time 100 events are recorded but not updated with data. I know the file has been recreated because I changed permissions to test, and permissions are reset each time.
Below are my configurations (With some actual data italicized/scrubbed):
Logstash-forwarder 3.1.1
Centos 6.5
/etc/logstash-forwarder
Note that the "paths" key does contain wildcards
{
"network": {
"servers": [ "*server*:*port*" ],
"timeout": 15,
"ssl ca": "/*path*/logstash-forwarder.crt"
},
"files": [
{
"paths": [
"/a/b/tomcat-*-*/logs/catalina.out"
],
"fields": { "type": "apache", "time_zone": "EST" }
}
]
}
Per logstash instructions for Centos 6.5 I have configured the LOGSTASH_FORWARDER_OPTIONS value so it looks like the following:
LOGSTASH_FORWARDER_OPTIONS="-config /etc/logstash-forwarder -spool-size 100"
Below is the resting state of the /.logstash-forwarder logrotate file:
{"/a/b/tomcat-set-1/logs/catalina.out":{"source":"/a/b/tomcat-set-1/logs/catalina.out","offset":433564,"inode":*number1*,"device":*number2*},"/a/b/tomcat-set-2/logs/catalina.out":{"source":"/a/b/tomcat-set-2/logs/catalina.out","offset":18782151,"inode":*number3*,"device":*number4*}}
There are two sets of logs that this is capturing. The offset has stayed the same for 20 minutes while activities have been occurred and sent over to Logstash.
Can anyone give me any advice on how to fix this problem whether it be a configuration setting I missed or a bug?
Thank you!
After more research I found it was announced that Filebeats is the preferred forwarder of choice now. I even found a post by the owner of Logstash-Forwarder that the program is full of bugs and is not fully supported any more.
I have instead moved to Centos7 using the latest version of the ELK stack, using Filbeats as the forwarder. Things are going much smoother now!