deno bundle misbehaving output

[tdillon]

I'm using Deno's bundle command to create a simple Lit web app. What I'm finding is the output of deno bundle for newer versions of Deno (anything after 1.4.6) actually changes the behavior of Lit. No errors are shown in the browser console, but the functionality appears to be broken. I assume Deno's newer bundling is different somehow and generates different output for the same input.

Here are 3 examples to show the behavior mentioned above. Browse to any of these pages, click the text, and the bolded text should update if everything is working.

• ✔️ Deno 1.4.6 example - works - main.js created by deno bundle
• ❌ Deno 1.16.4 example - does not work - main.js created by deno bundle
• ✔️ Lit Playground example - works - no Deno involvement

All of the source code and build commands can be found at
https://gitlab.com/tdillon/lit-deno-example/.

[kitsonk]

There was a significant update landed yesterday in main. Can you please try again with Deno canary? deno upgrade --canary or wait until next week for 1.17?

[tdillon]

Can you please try again with Deno canary? deno upgrade --canary or wait until next week for 1.17?

I tried with both canary and 1.17.0. Neither version fixed the issue.

[tdillon]

Deno 1.17.2 has resolved my issue. Besides some very minor formatting differences, the output of deno bundle in version 1.17.2 includes the following code which does not exist in the output from 1.17.1.

var own = Object.getOwnPropertyDescriptor(target, property);
if (own && (own.get || own.set)) {
    delete desc1.writable;
    delete desc1.initializer;

[tdillon]

The issue is back since it was briefly fixed with 1.17.2. I'm not sure which version caused the regression.

I've updated my issue reproduction page to simplify everything as well as include a working vanilla Lit implementation. For simplicity sake, I haven't implemented a page which shows Deno's behavior for each version (that seems like overkill), but I could make that happen if it would be helpful.

https://tdillon.gitlab.io/lit-deno-example/

Hope this helps.

[beingminimal]

@ry Just a feedback | New version release of deno without existing bug fixing will be useless for adoption of deno.
And soon deno will become new node only if we will not solve this soon. See open issues of bugs only in deno here https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aopen+label%3Abug
Let us know how can we make deno more reliable which will not break existing production workflow atlist.
Awaiting your response.

[beingminimal]

@bartlomieju @kitsonk @piscisaureus @caspervonb @lucacasonato
It's my humble request to solve this issue. It's breaking our production workflow.
So we are not able to ship new features and releases.
Please understand this urgent need and help to solve this issue.
Just we have tested and still this bug is there in new release v1.21.0
And please make sure how this type of bug can be prevented in future?
Awaiting your response.

[willmartian]

I believe this is the same issue as #14329.

Using declare with the Lit element decorator (as described in that issue) makes the component reactive.

---

Also @codecycleteam, I know this probably wasn't intentional, but it is typically considered rude to tag a bunch of maintainers on an issue. Hopefully this issue will be fixed soon, but in the mean time you can try the workaround above ^

[tdillon]

Lit's documentation aligns with #13281.

https://lit.dev/docs/components/properties/#avoiding-issues-with-class-fields

For TypeScript, you may use class fields for declaring reactive properties as long as the useDefineForClassFields setting in your tsconfig is set to false.

I assume we just have to wait until the spec is finalized for the proper behavior without any sort of workaround.