I've been rendering jsreport PDFs succesfully on my development machine. However, when running jsreport on the test server PhantomJS is falling back the use the default font. Any idea how to solve or troubleshoot?
I'm using Handlebars and PhantomJS. Dev machine spec: jsReport 1.0.7 on Node v4.4.5 on 64 bit Win10. Test server spec: jsReport 1.0.7 on Node vx.x.x on 64 bit Win2012 R2 Server
Steps to reproduce:
1) Upload fonts to jsReport
fonts uploaded to jsreport
When selected, jsReport suggests using it as below:
{#image MavenPro-Black #encoding=base64}
2) Add the “Shortcut” to the data file
{
"assets": {
"MavenPro-Black": "{#image MavenPro-Black}",
"MavenPro-Bold": "{#image MavenPro-Bold}",
"MavenPro-Medium": "{#image MavenPro-Medium}",
"MavenPro-Regular": "{#image MavenPro-Regular}",
"jquery": "{#image jquery}"
},
……
}
3) Use the asset in the Report
<head>
<script src="{{assets.jquery}}"></script>
<style>
/* Common Classes */
#font-face {
font-family: 'Maven Pro';
src: url({{assets.MavenPro_Regular}}) format('truetype');
}
The reason that it works on your local is because you have probably this font already installed. The reason why it cannot work on the server is because you have typo in your code:
You data includes property MavenPro-Regular, but in template you access it using {{assets.MavenPro_Regular}}. You just need to change - to _ in your data and it should work.
Working example:
https://playground.jsreport.net/studio/workspace/SklZyycYg/9
Hint 1: Use text recipe and print the raw output to troubleshoot such problems. You would immediately see that the url of font is not filled.
Hint 2: You should consider using jsreport assets feature to embed fonts rather than images extension. You can find demo how to use it with description here.
Edit
Assets extension is part of the default installation and can be considered stable since version 1.3.0
Related
I'm building a Vue.js application using Vuexy BootstrapVue template, deployed in a Docker container.
I am finding that when we deploy updates to our web app, that the User has to do a hard-refresh in their browser to load the latest version of the app, otherwise they'll be navigating around a cached version.
Is there a way for me to force a client browser to load the latest version for a User?
Either on every load, or every few hours?
(I've tagged Bootstrap-Vue for transparency, but don't actually know if it has any bearing on this issue)
You are facing the cache problem and there is multiple ways to handle this.
Cache Control
You can control the cache with the header with max-age or no-store, no-cache to simple disable it, like this question/answer: How do we control web page caching, across all browsers?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
https://csswizardry.com/2019/03/cache-control-for-civilians/
Cache busting
Aappending a version (example: 1.0.0) to query string of the script tag:
<script src="path/to/your/app.min.js?v=1.0.0"
and change that version for every build.
Hashing the script file
You can also use some webpack/rollup config to build the script with a hash, like app.bf43112.js
webpack
const config = {
output: {
path: PATHS.build,
filename: "[name].[contenthash].js",
},
};
Rollup
const isProduction = process.env.NODE_ENV === 'production';
export default {
output: {
sourcemap: true,
format: 'iife',
name: 'app',
file: isProduction ? 'bundle[hash].js' : 'public/build/bundle.js',
}
};
Reference: Hashed file names using Rollup
Service Worker
Another solution, that I never tested, but sounds a good method.. is creating a service worker to control how retrieve the js file:
https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker
You can do things like deleting the cache, responding the cache with a response that you manually fetch with js, etc.
Summary:
I have created projects, with Vue.js and Nuxt.js, where I have installed aws-amplify (which automatically installs aws-sdk) in order that I can implement authentication with AWS Cognito.
In both cases, this works very nicely, but the problems come when I build production versions.
In both cases, I end up with massive bundle sizes which (thanks to webpack-bundle-analyzer) I can immediately see are caused by the aws-sdk which appears to contain code to implement every AWS service, under the sun, despite the fact that I am only importing AWS Cognito's: "Auth" (import { Auth } from 'aws-amplify')
I have tried creating a custom AWS SDK for JavaScript, which only includes the service: AWS.CognitoIdentity, but despite incorporating that (presumably incorrectly), I still end up with the same bundle size (and aws-sdk files) when I build the projects.
As I say, this is happening in both Nuxt and Vue project, but in order to simplify this, I for now just want to find the solution to a very basic sample project created with Vue.
I think I must be doing something dumb, but I can't work out what that is.
Any help would be greatly appreciated! :-)
Steps to reproduce:
Create a basic Vue.js project with defaults. Run: vue create vue-aws-sdk-inv
[Note: Steps 2 - 4, are not crucial to reproduce issue, but install webpack-bundle-analyzer which provides useful extra info.]
In the new project, install webpack-bundle-analyzer. Run: npm install --save-dev webpack-bundle-analyzer
Create root file: vue.config.js
Add the following code to vue.config.js:
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer")
.BundleAnalyzerPlugin;
module.exports = {
configureWebpack: {
plugins: [new BundleAnalyzerPlugin()]
}
};
As a benchmark, build the project. Run: npm run build
At this stage, the project will build (with no console warnings) and webpack-bundle-analyzer will launch (in the browser) showing the file: chunk-vendors..js, at the top of the tree, containing a bunch of other .js files, all of acceptable size.
Install AWS Amplify (and by default aws-sdk). Run: npm i aws-amplify
Open src/components/HelloWorld.vue and add the following under the tag: import { Auth } from "aws-amplify";
Build the project. Run: npm run build
At this stage, the project will build WITH console warnings regarding the following files being too large:
File Size Gzipped
dist/js/chunk-vendors.013ac3f0.js 3055.78 KiB 550.49 KiB
dist/js/app.fa2a21c4.js 4.67 KiB 1.67 KiB
dist/css/app.53019c4c.css 0.33 KiB 0.23 KiB
If installed, webpack-bundle-analyzer should launch (in the browser) showing an inflated: chunk-vendors..js, due to a hefty: aws-sdk.
aws-sdk will include api: .json files and lib: .js files for every AWS service I can think of!
The attempt to rectify:
Navigate to: https://sdk.amazonaws.com/builder/js/
Clear all services.
Select just: AWS.CognitoIdentity
Download "Minified" aws-sdk-.js
Download "Default" aws-sdk-.min.js
[Note: the following are the steps I am guessing I'm getting wrong?...]
In the project, search the node_modules directory for aws-sdk.js and aws-sdk.min.js.
They were found in /node_modules/aws-sdk/dist
Replace both files with the downloaded files (renaming to aws-sdk.js and aws-sdk.min.js respectively.)
Build the project. Run: npm run build
Project will build with same console warnings and same massive aws-sdk, as before, containing all the same .js and .json files for a bunch of services that are not actually imported in the application.
Final pieces of analysis:
Remove aws-sdk.js and aws-sdk.min.js from project's: /node_modules/aws-sdk/dist
Build the project. Run: npm run build
Project is built without even referencing these files.
Rename /node_modules/aws-sdk to /node_modules/TEMP_aws-sdk and attempt to build the project.
Build fails, and this proves (I think) that I was at least trying to add the custom versions, of aws-sdk.js and aws-sdk.min.js, somewhere in the correct directory!
Source Code:
vue.config.js:
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer")
.BundleAnalyzerPlugin;
module.exports = {
configureWebpack: {
plugins: [new BundleAnalyzerPlugin()]
}
};
src/components/HelloWorld.vue:
import { Auth } from "aws-amplify";
As said before, any help would be greatly appreciated! :-)
It looks like import { Auth } from "aws-amplify"; doesn't currently allow for tree shaking according to this issue.
Reading through several related issues, it appears that:
import Auth from '#aws-amplify/auth';
is the best you can currently do. I suspect that over time, the AWS team will figure out a way to better separate the internals.
For readers looking for a way to reduce bundle sizes for the aws-sdk package, see this section of the docs.
In my case:
import S3 from 'aws-sdk/clients/s3';
import AWS from 'aws-sdk/global';
cut the bundle size down by quite a lot. That gets it down to ~57k gz to use S3.
Also, for anyone using nuxt you can just run nuxt build -a to get the build analyzer.
I've got an existing code base in which Vue.js has performance problems. I also see this notice in the browser console:
so I guess an easy fix could be to put Vue into production mode.
In the suggested link I try to follow the instructions for webpack. We're on Webpack version 2.7 (current stable version is 4.20). In the instructions it says that in Webpack 3 and earlier, you’ll need to use DefinePlugin:
var webpack = require('webpack')
module.exports = {
// ...
plugins: [
// ...
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('production')
})
]
}
So in my package.json I've got a build script defined:
To build for production I run yarn run build and it runs a build.js file (paste here) which in turn calls webpack.base.conf.js (paste here) and webpack.prod.conf.js (paste here).
As you can see in the paste I use the DefinePlugin as suggested by the docs.
I also found a file called vue-loader.conf.js (paste here) and to be sure I also added the DefinePlugin in there as well.
I can run yarn run build which ends without errors, but when serve the site over Apache and open the browser it still shows the notification that we're in development mode.
To be sure it actually uses the files created by webpack I completely removed the folder /public/webpack/ and checked that the webinterface didn't load correctly without the missing files and then built again to see if it loaded correctly after the command finished. So it does actually use the files built by this webpack process. But Vue is actually not created in production mode.
What am I doing wrong here?
The problem may be in your 'webpack.base.conf.js' as i suspected, thank you for sharing it, upon searching i've found an issue resolving your 'production not being detected' problem on github here
The solution requires that you change 'vue$': 'vue/dist/vue' to 'vue$': vue/dist/vue.min in production.
You will find the original answer as:
#ozee31 This alias 'vue$': 'vue/dist/vue' cause the problem, use vue/dist/vue.min in production environment.
I am using WebdriverIO/Cucumber (wdio-cucumber-framework) for my test automation. I want to get the test execution result in a HTML file. As of now I am using Spec Reporter (wdio-spec-reporter). Which helps to print the results in console window. But I want all the execution reports in a HTML file.
How can I get WebdriverIO test execution result in a HTML file?
Thanks.
OK, finally got some spare time to tackle your question #Thangakumar D. WebdriverIO reporting is a vast subject (there are multiple ways to generate such a report), so I'll go ahead and start with my favorite reporter: Allure!
Allure Reporter:
[Preface: make sure you're in your project root]
Install your package (if you haven't already): npm install wdio-allure-reporter --save-dev
Install Allure CommandLine (you'll see why later): npm install -g allure-commandline --save-dev
Setup your wdio.config.js file to support Allure as a reporter
wdio.config.js:
reporters: ['allure', 'dot', 'spec', 'json'],
reporterOptions: {
outputDir: './wdio-logs/',
allure: {
outputDir: './allure-reports/allure/'
}
}
Run your tests! Notice that, once your regression ends, your /allure-results/ folder has been populated with multiple .json, .txt, .png (if you have screenshot errors), and .xml files. The cotent of this folder is going to be used by Allure CommandLine to render you HTML report.
Go to your /allure-results/ folder and generate the report via: allure generate <reportsFolderPath> (do it like this allure generate .
If you want your /allure-reports/ folder inside /allure-results/)
Now go into your /allure-reports folder and ope index.html into your browser of choice (use Firefox for starters)
Note: The generated index.html file won't have all the content loaded on Chrome unless you do some tweaks. It's due to default WebKit not being able to load all the AJAX calls required. Read more about it here.
If you're successfully completed all the previous steps, it should look something like this:
Hope this helped. Cheers!
Note: I'll try to UPDATE this post when I get some more time with other awesome ways to generate reports from your WebdriverIO reporter logs, especially if this post gets some love/upvotes along the way.
e.g.: Another combo that I enjoy using being: wdio-json-reporter/wdio-junit-reporter coupled with a easy-to-use templating language, Jinja2.
I have been using Mochawesome reporter and it looks beautiful, check it out
here.
Mochawesome reporter generates the mochoawesome.json which then can be used to create a beautiful report using Mochawesome report generator
Installation:
> npm install --save wdio-mochawesome-reporter
> npm install --save mochawesome-report-generator#2.3.2
It is easier to integrate by adding this line in the wdio.conf.js:
// sample wdio.conf.js
module.exports = {
// ...
reporters: ['dot', 'mochawesome'],
reporterOptions: {
outputDir: './', //mochawesome.json file will be written to this directory
},
// ...
};
Add the script to package.json:
"scripts": {
"generateMochawesome": "marge path/to/mochawesome.json --reportTitle 'My project results'"
},
There is a javascript library, pre-built and available on npm, that I wish to develop with/debug. In my case, it is openlayers.
In the classic way of requiring a javascript file and wanting to debug, one would just switch the script url from the production version to the debug version, ie:
to
However, when using webpack and then importing via npm:
import openlayers from 'openlayers'
Gets you the production distribution of the library, the same as the ol.js script from above.
On a side note, to stop webpack trying to parse a prebuilt library and throw a warning about that you must include something like this:
// Squash OL whinging
webpackConfig.module.noParse = [
/\/dist\/ol.*\.js/, // openlayers is pre-built
]
Back to the problem at hand: how can I conditionally load a different entry-point for a module prebuilt and imported like this?
Of course, I can do it in a hacky way. By going into the node_modules/openlayers/package.json and switching the browser field from
"browser": "dist/ol.js",
to
"browser": "dist/ol-debug.js",
Is there a way I can request a different entry point via webpack or by using a different import syntax? Do I first have to petition the library maintainers to update the browser field to allow different entry point hints to browsers, according to the spec? https://github.com/defunctzombie/package-browser-field-spec
Thoughts on a more effective way to make this happen? Yearning to be able to programmatically switch loading of the production and debug versions of a library based on env variables.
Webpack has configuration options for replacing a module into a different path: https://webpack.github.io/docs/configuration.html#resolve-alias
This resolves the openlayers import to use the debug version:
webpackConfig.resolve.alias: {
openlayers: 'openlayers/dist/ol-debug.js'
}
In my build system I have a function that takes the environment type and returns the matching webpackConfig. Based on the parameter I include the above snippet or not.
Full code: webpack-multi-config.js
I have two different (gulp-) tasks for development and production. For example the production task: webpackProduction.js
Line 1 imports the config script with production as type.
My build system is based on gulp starter.