I'm sort of stuck with one problem and googling it for about three hours brought me nowhere.
Here's the problem. I'm trying to develop my own custom PDF viewer based on PDF.JS lib. Officially it is distributed on npm as pdfjs-dist package. However I need to extend a few classes that are not accessible in pdfjs-dist. So I npm install'ed or yarn add'ed the original repo https://github.com/mozilla/pdf.js.git. This way I have access to classes I need. Inside pdf.js there are core lib that is stored in pdf.js/src/ and a pdf-viewer app that is stored in pdf.js/web/.
Inside that pdf.js/web/ app core lib (pdf.js) is referenced via pdfjs-lib alias that is resolved to pdf.js/src/ during pdf.js inner build process by gulp.
For example pdf.js/web/base_viewer.js:
import { AnnotationLayerBuilder } from './annotation_layer_builder';
import { createPromiseCapability } from 'pdfjs-lib';
import { PDFPageView } from './pdf_page_view';
So now I'm trying to import that pdf.js/web/base_viewer.js in my app that is using latest Webpack 4 (I guess), and this pdfjs-lib sub-dependency is not resolved.
I've tried webpack's resolve-alias mechanism (https://webpack.js.org/configuration/resolve/):
resolve: {
alias: {
'pdfjs-lib': path.resolve(__dirname, './node_modules/pdf.js/src/')
},
}
...but looks like it resolves dependencies only of my own App, but not sub-dependencies of my dependency.
Just in case I'm building Vue 3.0 app using vue-cli and access webpack config this way: https://cli.vuejs.org/guide/webpack.html, but don't think it matters.
Any help from Webpack gurus here?
Thanks.
Related
I am new to Vite and Vitest. I am experimenting a little bit, trying to add Vitest to a React-native app. I know Vite doesn't really support React Native but I would like to trying running just the tests with Vitest.
I get an error when trying to import React-native modules:
Module .../node_modules/react-native/index.js:14 seems to be an ES Module but shipped in a CommonJS package. You might want to create an issue to the package "react-native" asking them to ship the file in .mjs extension or add "type": "module" in their package.json.
As a temporary workaround you can try to inline the package by updating your config:
// vitest.config.js
export default {
test: {
deps: {
inline: [
"react-native"
]
}
}
}
When adding the suggested config the tests break inside React-native instead, as if the modules in fact is not supported.
What is going on here? Is React-Native only published as commonjs modules, while only esm-modules is supported by Vite? Is there a way around it?
Thanks in advance,
M.
As you can see in the bundle analyzer screenshot, our app is using both the es and lib modules from antd (this is when building for production as well as development).
The app was init:ed with CRA and we use craco to override some webpack settings, this is the only thing related to antd that we do in craco.config.js:
plugins: [
{
plugin: CracoAntDesignPlugin,
options: {
customizeTheme: antd_overrides,
},
},
],
We always use the es style import of import { Button } from 'antd'.
Is there a "simple" way to only keep the es modules? Also, I'm guessing tree-shaking isn't happening as we don't actually import 288 modules from antd... but that's a different issue I'm guessing.
I've found this on the subject: https://habr.com/en/company/vk/blog/537880/, but uncertain as to how to go about the things under the hood of CRA (babel for one).
Any help and suggestions greatly appreciated.
Could it potentially be this:
import frFR from 'antd/lib/locale-provider/fr_FR';? As I'm importing from lib? Doesn't seem to be exported as an es module thou.
Dear Stack Overflow / Vue.js / Rollup community
This could be a noob question for the master plugin developers working with Vue and Rollup. I will write the question very explicitly hoping that it could help other noobs like me in the future.
I have simple plugin that helps with form validation. One of the components in this plugin imports Vue in order to programatically create a component and append to DOM on mount like below:
import Vue from 'vue'
import Notification from './Notification.vue' /* a very simple Vue component */
...
mounted() {
const NotificationClass = Vue.extend(Notification)
const notificationInstance = new NotificationClass({ propsData: { name: 'ABC' } })
notificationInstance.$mount('#something')
}
This works as expected, and this plugin is bundled using Rollup with a config like this:
import vue from 'rollup-plugin-vue'
import babel from 'rollup-plugin-babel'
import { terser } from 'rollup-plugin-terser'
import resolve from 'rollup-plugin-node-resolve'
import commonjs from 'rollup-plugin-commonjs'
export default {
input: 'src/index.js',
output: {
name: 'forms',
globals: {
vue: 'Vue'
}
},
plugins: [
vue(),
babel(),
resolve(),
commonjs(),
terser()
],
external: ['vue']
}
As you can see, Vue.js is getting externalised in this bundle. The aim (and the assumption) is that the client app that imports this plugin will be running on Vue, therefore there's no need to bundle it here (assumption).
The very simple src/index.js that the bundler uses is below:
import Form from './Form.vue'
export default {
install(Vue, _) {
Vue.component('bs-form', Form)
}
}
Rollup creates 2 files (one esm and one umd) and references them in in the plugins package.json file like below:
"name": "bs-forms",
"main": "./dist/umd.js",
"module": "./dist/esm.js",
"files": [
"dist/*"
],
"scripts": {
"build": "npm run build:umd & npm run build:es",
"build:es": "rollup --config rollup.config.js --format es --file dist/esm.js",
"build:umd": "rollup --config rollup.config.js --format umd --file dist/umd.js"
}
Everything works as expected up to this point and the bundles are generated nicely.
The client app (Nuxt SSR) imports this plugin (using npm-link since it's in development) with a very simple import in a plugin file:
/* main.js*/
import Vue from 'vue'
import bsForms from 'bs-forms'
Vue.use(bsForms)
This plugin file (main.js) is added to nuxt.config.js as a plugin:
// Nuxt Plugins
...
plugins: [{src: '~/plugins/main'}]
...
Everything still works as expected but here comes the problem:
Since the clients is a Nuxt app, the Vue is imported by default of course but the externalised Vue module (by the forms plugin) is also imported in the client. Therefore there is a duplication of this package in the client bundle.
I guess the client app can configure its webpack config in order to remove this duplicated module. Perhaps by using something like a Dedupe plugin or something? Can someone suggests how to best handle situation like these?
But what I really want to learn, is the best practice of bundling the plugin at the first place, so that the client doesn't have to change anything in its config and simply imports this plugin and move on.
I know that importing the Vue.js in the plugin may not be a great thing to do at the first place. But there could be other reasons for an import like this as well, for example imagine that the plugin could be written in Typescript and Vue.js / Typescript is written by using Vue.extend statements (see below) which also imports Vue (in order to enable type interface):
import Vue from 'vue'
const Component = Vue.extend({
// type inference enabled
})
So here's the long question. Please masters of Rollup, help me and the community out by suggesting best practice approaches (or your approaches) to handle situations like these.
Thank you!!!!
I had the same problem and I found this answer of #vatson very helpful
Your problem is the combination of "npm link", the nature of nodejs module loading and the vue intolerance to multiple instances from different places.
Short introduction how import in nodejs works. If your script has some kind of library import, then nodejs initially looks in the local node_modules folder, if local node_modules doesn't contain required dependency then nodejs goes to the folder above to find node_modules and your imported dependency there.
You do not need to publish your package on NPM. It is enough if you generate your package locally using npm pack and then install it in your other project npm install /absolute_path_to_your_local_package/your_package_name.tgz. If you update something in your package, you can reinstall it in your other project and everything should work.
Here is the source about the difference between npm pack and npm link https://stackoverflow.com/a/50689049/6072503.
I have sorted this problem with an interesting caveat:
The duplicate Vue package doesn't get imported when the plugin is used via an NPM package (installed by npm install -save <plugin-name> )
However, during development, if you use the package vie npm link (like npm link <plugin-name>) then Vue gets imported twice, like shown in that image in the original question.
People who encounter similar problems in the future, please try to publish and import your package and see if it makes any difference.
Thank you!
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.
After bundling a simple aurelia application with jspm bundle-sfx I get the following error:
No PLATFORM.Loader is defined and there is neither a System API (ES6) or a Require API (AMD) globally available to load your app.
An example application: https://github.com/Baudin999/jspm-bundling-test
You can use: npm run setup:dev in a non windows env to switch back to the dev settings (which is just a comment/uncomment in the ./src/client/index.html) and you can use npm run setup:prod to switch back to the production environment, bundling will automatically be triggered. all other scripts can be found in the package.json.
I can't link to other questions because I haven't found any questions which relate to this problem. I "think" (which means absolutely nothing) that this might be related to the fact that aurelia needs a full loader even when bundling with bundle-sfx but I haven't found any ways to solve the error.
EDIT (25/01/2017 17:16): I've found out that the error is because I import the aurelia-bootstrapper.
As soon as I add: import * as bootstrapper from 'aurelia-bootstrapper'; I get the error
Please add the code how do you bootstrap your aurelia app.
There is nothing actually to import from bootstrapper apart from bootstrap function.
Which you would use in case of custom manual bootstrapping.
like in
import { bootstrap } from 'aurelia-bootstrapper'
const configure: (au: Aurelia) => {} = async function (au: Aurelia) {
au.use
.standardConfiguration();
await au.start()
au.setRoot() // or au.enchance()
})
bootstrap(configure)
in a happy path scenario with jspm - you System.import('aurelia-bootstrapper')
and it takes over finding the root node of your app and the script to configure Aurelia (main by default)
Have a look at Bootstrapping Aurelia in the docs
Oh.. and bundle-sfx is not supported there are other means to bundle aurelia apps using jspm