Open Artur- opened 2 years ago
Another case, possible with the same cause, is when using iron-icon from https://github.com/PolymerElements/iron-icon/blob/v3.0.1/iron-icon.js
This imports iron-meta https://github.com/PolymerElements/iron-icon/blob/v3.0.1/iron-icon.js#L13
iron-meta.js defines a custom element https://github.com/PolymerElements/iron-meta/blob/v3.0.1/iron-meta.js#L135
Yet when iron-icon creates a <iron-meta>
tag https://github.com/PolymerElements/iron-icon/blob/v3.0.1/iron-icon.js#L138, the custom element has not yet been defined.
I was not able to create a reduced test case for this one but it reproduces in one of our application.
@patak-js Hi, this issue is very important for us to get Vite integration working at Vaadin.
The problem appears to be quite severe: running code in the wrong order may cause unpredictable consequences. Would you have time to look into this issue and maybe give some pointers about the root cause?
I'm not sure it's a bug of Vite. If you just switch these two lines.
And it works. Maybe the cause it's the difference of "import order" between cjs and esm.
A simplified test is
import '@polymer/polymer/polymer-legacy.js';
import "@polymer/polymer/lib/utils/debounce.js";
import '@polymer/polymer/lib/elements/dom-module.js';
import '@polymer/iron-media-query/iron-media-query.js';
Now what happens in the browser is polymer-legacy.js. becomes
import {
Base,
Polymer,
html
} from "/@fs/Users/artur/test/vite-vaadin-problem1/node_modules/.vite/chunk-E37EP5WI.js?v=7f8f8d06";
import "/@fs/Users/artur/test/vite-vaadin-problem1/node_modules/.vite/chunk-XMBTGBNN.js?v=7f8f8d06";
import "/@fs/Users/artur/test/vite-vaadin-problem1/node_modules/.vite/chunk-2ZES3KKB.js?v=7f8f8d06";
import "/@fs/Users/artur/test/vite-vaadin-problem1/node_modules/.vite/chunk-T5UZQ2GC.js?v=7f8f8d06";
The chunk E37EP5WI
contains the code from iron-media-query.js
which means that its side effects are executed first.
The common dependency, which absolutely must be run before, is included in the chunk T5UZQ2GC
// node_modules/@polymer/polymer/lib/utils/boot.js
window.JSCompiler_renameProperty = function(prop, obj) {
return prop;
};
and that is executed last
My reproduction and the result is the same with @Artur-
import '@polymer/iron-list/iron-list.js';
import { Debouncer } from "@polymer/polymer/lib/utils/debounce.js";
import '@vaadin/vaadin-grid-pro/theme/lumo/vaadin-grid-pro-edit-column.js';
import '@vaadin/vaadin-lumo-styles/color.js';
Minimal reproducible example with esbuild:
esbuild \
./node_modules/@polymer/polymer/polymer-legacy.js \
./node_modules/@polymer/polymer/lib/utils/debounce.js \
./node_modules/@polymer/polymer/lib/elements/dom-module.js \
./node_modules/@polymer/iron-media-query/iron-media-query.js \
--bundle --splitting --outdir=out --format=esm
Maybe related: https://github.com/evanw/esbuild/issues/399
Describe the bug
With suitable imports, it seems that the following code
can execute so that
observedAttributes
is run before the globalJSCompiler_renameProperty
has been set, resulting inThis only happens with some specific imports, as shown in the test case.
Reproduction
Open localhost:3000 and look at the console output. There should be no errors.
System Info
Used Package Manager
npm
Logs
No response
Validations