Import variables from entry modules #654
Replies: 1 comment
-
This is likely also out of scope even for upstream parcel/swc/esbuild re:how tree shaking/module import works, IMO. On one-hand, you cannot tree-shake side-effect code (such as root-level event listener or root-level function invocation <- the side-effect is included at runtime to produce the export, unless you somehow explicitly declare that such root-level invocation doesn't alter your exported output, which render the whole file "static' instead of runtime-level import). This can be done with either a decorator or some special annotation, but it would further complicate the syntax of your file On the other hand, entry modules are not meant for exporting code to be reused. Since they get pickup by the bundle as the entry index, we kinda want to reduce the external export interface as much as possible to avoid complication for the bundler. My recommendation is to just have a shared |
Beta Was this translation helpful? Give feedback.
-
What happened?
Auto-closing this bug as I'm simply documenting for others; expecting it to be out of scope but feel free to re-open if not.
newtab.tsx
andbackground.ts
pagebackground.ts
page (occurred withenum
but justtype
may cause it too)background.ts
into thenewtab.tsx
pageExpected: some kind of warning or some clever code segmentation.
Actual Result: Two instances of all the code in
background.ts
running -- one as a service worker and the other as part of the new tab page or maybe a content script. All listeners (iechrome.runtime.onConnect
) added twice, lots of head-scratching bugs, ect.Version
Latest
What OS are you seeing the problem on?
Linux
What browsers are you seeing the problem on?
Chrome
Relevant log output
No response
(OPTIONAL) Contribution
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions