SolidJS•3mo ago

Side effect in bundled code `ie(["click", "keydown"]);`

I'm trying to import types from a lib I'm building that contains a Solid.js component. However, when building using a vanilla Vite + Solid setup, the lib's build output has a top-level call to ie(["click", "keydown"]); . In turn, this call is added to the output build of the second package. Where is this coming from? Can Solid.js be fixed to not produce these top level function calls?

21 Replies

aryzing•3mo ago

This is what gets added to the second package when importing only types from the first (which has the Solid.js component),

const Oe = "_$DX_DELEGATE";
function ie(e, t = window.document) {
  const n = t[Oe] || (t[Oe] = /* @__PURE__ */ new Set());
  for (let i = 0, r = e.length; i < r; i++) {
    const s = e[i];
    n.has(s) || (n.add(s), t.addEventListener(s, Vt));
  }
}
function Vt(e) {
  const t = `$$${e.type}`;
  let n = e.composedPath && e.composedPath()[0] || e.target;
  for (e.target !== n && Object.defineProperty(e, "target", {
    configurable: !0,
    value: n
  }), Object.defineProperty(e, "currentTarget", {
    configurable: !0,
    get() {
      return n || document;
    }
  }); n; ) {
    const i = n[t];
    if (i && !n.disabled) {
      const r = n[`${t}Data`];
      if (r !== void 0 ? i.call(n, r, e) : i.call(n, e), e.cancelBubble)
        return;
    }
    n = n._$host || n.parentNode || n.host;
  }
}
ie(["click", "keydown"]);
ie(["click", "keydown"]);
ie(["click", "keydown"]);

const Oe = "_$DX_DELEGATE";
function ie(e, t = window.document) {
  const n = t[Oe] || (t[Oe] = /* @__PURE__ */ new Set());
  for (let i = 0, r = e.length; i < r; i++) {
    const s = e[i];
    n.has(s) || (n.add(s), t.addEventListener(s, Vt));
  }
}
function Vt(e) {
  const t = `$$${e.type}`;
  let n = e.composedPath && e.composedPath()[0] || e.target;
  for (e.target !== n && Object.defineProperty(e, "target", {
    configurable: !0,
    value: n
  }), Object.defineProperty(e, "currentTarget", {
    configurable: !0,
    get() {
      return n || document;
    }
  }); n; ) {
    const i = n[t];
    if (i && !n.disabled) {
      const r = n[`${t}Data`];
      if (r !== void 0 ? i.call(n, r, e) : i.call(n, e), e.cancelBubble)
        return;
    }
    n = n._$host || n.parentNode || n.host;
  }
}
ie(["click", "keydown"]);
ie(["click", "keydown"]);
ie(["click", "keydown"]);

Brendonovich•3mo ago

are you using import type {} from "package"? that should prevent the package's code from actually being imported, unless you're importing it somewhere else also if you're developing a package and not an app, you shouldn't be bundling dependencies

aryzing•3mo ago

Yes, or rather, the equivalent import { type Foo } from "package"; The snippet above gets included b/c it's considered a side effect regardless of what gets imported I believe the first (library) package has to contain some Solid.js code because I'm building a web component with Solid.js and solid-element (https://github.com/solidjs/solid/tree/main/packages/solid-element#readme) The web component is available to consumers, as well as some types

Brendonovich•3mo ago

yeah since it's a package you'll want to only distribute your package's code, bundling in solid and solid-element and everything else should be left up to the builder used by the end user for making solid libraries i like to use tsup + this preset rather than vite, it makes sure that only your library's code is built + adds the appropriate exports

aryzing•3mo ago

Thanks for the recommendation!

Brendonovich•3mo ago

i'm not too familiar with web components but this is something you'd consume with an npm install and a js import yeah?

aryzing•3mo ago

I guess I was trying to provide a fully functional web component, hence it feels weird that consumers have to import solid -- they may not even be able to if they're in a pure web environement Essentially, the web component is packaged and ready to be included in any HTML doc without requiring external dependencies correct I think it would be fair to say it's not a solid library, it's a lib that contains a web component that just happens to be built with Solid.js

Brendonovich•3mo ago

hmm, that sounds more similar to the app than library use case since they should be standalone web components. you probably do want to bundle in solid in that case

aryzing•3mo ago

I think so too 😅

Brendonovich•3mo ago

in that case what's wrong with the sideeffect being included?

aryzing•3mo ago

Great question! Next.js 😮‍💨

Brendonovich•3mo ago

ffs i thought web components were isolated or something?

aryzing•3mo ago

Some users are rendering the web component using Next.js, which when rendering on the server errors out due to window being included Yes, they are isolated, but the bundle contains those pesky ie() calls

Brendonovich•3mo ago

omg ssring a solid webcomponent and getting a window undefined error is the most obscure problem ever since solid requires different compilation for client and server yeah i have no idea what you'd do about that haha

aryzing•3mo ago

When the component is simple, there are no issues When the click handlers start to get added, that's when Solid.js generates side effect functions that then interfere with Next.js

Brendonovich•3mo ago

yeahhh, those listeners wouldn't be added in the version compiled for server

aryzing•3mo ago

Alright, maybe I have to look into that, although I'm leaning towards dropping Next.js support, b/c consumers need to be able to freely import the bundle on the browser Much appreciate your help @Brendonovich 🙏

Brendonovich•3mo ago

yeah on the browser it should be fine, you'd be missing ssr support in general though rather than just nextjs support maybe you'd have to require that next/dynamic is used to make it client only

aryzing•3mo ago

Yeah, I'll add that to the docs and call it a day

Brendonovich•3mo ago

even with solid start you'd need to use clientOnly

aryzing•3mo ago

Fixed it! Switched from synthetic events (on__) to native events (on:__)

Gaming

Programming

Side effect in bundled code `ie(["click", "keydown"]);`