Open npellegrin opened 1 year ago
I managed to put a breakpoint in the Amplify.addPluggable
function call at runtime, and the bug seems to be related to the _components
list of the Amplify object not having a PubSub object instance. This explain why the addPluggable instruction is never forwarded to PubSub component, but I did not managed to understand how the _component
should have been populated at this step.
Below, the production-minified code of the Amplify function, with some watchers : The screenshot correspond to this line is source code: https://github.com/aws-amplify/amplify-js/blob/e1b0b5be3e8ccb3c76e8e2e2f43f910d40d73254/packages/core/src/Amplify.ts#L80
Ok, I found it... The _components
attribute is populated when register() function is called in the Amplify object. This call is performed automatically uppon import, at : https://github.com/aws-amplify/amplify-js/blob/5147c5ce555d042722e2888fc423430f517b91b7/packages/pubsub/src/PubSub.ts#L177
This import is clearly specified in the documentation, and the initialization should be performed as this:
However, following strictly this documentation will not work in production builds, because minifiers will drop the unused PubSub import because it is actually never used in my boot()
function (it is only used when performing subscribe later in the app), consequently, the Amplify.addPluggable
fail silently and nothing is really plugged to the PubSub module.
I fixed my app by forcing the registration before calling addPluggable, or artificially using the PubSub module in my boot function. Below the both working hacks:
PubSub.getModuleName();
Amplify.addPluggable(
new AWSIoTProvider({
aws_pubsub_region: '',
aws_pubsub_endpoint: ''
})
);
Amplify.register(PubSub);
Amplify.addPluggable(
new AWSIoTProvider({
aws_pubsub_region: '',
aws_pubsub_endpoint: ''
})
);
I guess the documentation should be updated to warn about this side effect, or the behavior of addPluggable may be improved to prevent minifiers missing the register() function call before Amplify.addPluggable.
Thanks for reporting this @npellegrin and digging into the problem/solution.
I am encountering the same issue with vite production build and react. The above fix(es) work for me as well.
versions
"aws-amplify": "^5.2.2"
"vite": "^3.2.3"
Moving this issue to the amplify-docs
repo. There needs to be updates to both the v5 and the v6 code examples for PubSub based on the workarounds and details in this issue.
Before opening, please confirm:
JavaScript Framework
Vue
Amplify APIs
PubSub
Amplify Categories
Not applicable
Environment information
Describe the bug
This may be related to aws-amplify/amplify-js#10829. It could be related to my implementation of the Amplify initialization in Quasar.
When using the PubSub module, websockets are not opened by the framework with production builds. There is no error message. Development builds works properly.
Expected behavior
Websockets should be opened on both development build and production builds.
Reproduction steps
I have a Vue.js application, built with Vite and Quasar. Versions are:
I setup Amplify during the Quasar boot and the Amplify init looks like this:
And the subscription is performed like this:
Also, I have in my index.html and quasar.config.js the magic lines to make Amplify work with production packaging:
index.html
quasar.config.js:
When testing the application with
quasar dev
, the subscription is performed. With a production build, the websocket request is never opened by the web browser, but no error message is shown.Additional information and screenshots
With
Amplify.Logger.LOG_LEVEL = 'DEBUG'
activated, production builds have no reference to MqttOverWSProvider in the logs, when dev builds properly show the MqttOverWSProvider, and it work.I found a possible workaround, it seems that adding the AWSIoTProvider pluggable directly using the PubSub API instead of using the Amplify API API works: