v0.26 does not build with lit-recommended tools for experimental bare module exports

[christophe-g]

Thanks for the new release.

There are a couple of import statement breaking the library to run with the frontend tooling I am using (vite.js):

• import {customElement} from 'lit/decorators' -> import {customElement} from 'lit/decorators.js' (see https://lit.dev/docs/components/decorators/#importing-decorators, or Missing "./decorators/custom-element" export in "lit" package lit/lit#2206 (comment));
• similarly, all directive imports should have the .js extension specified. For instance import { styleMap } from 'lit/directives/style-map' -> import { styleMap } from 'lit/directives/style-map.js'

Without this, build tools fail to find dependencies:

 The plugin "vite:dep-pre-bundle" was triggered by this import

    node_modules/.pnpm/@material+mwc-dialog@0.26.0/node_modules/@material/mwc-dialog/mwc-dialog.js:9:30:
      9 │ import { customElement } from 'lit/decorators';
        ╵                               ~~~~~~~~~~~~~~~~

✘ [ERROR] [plugin vite:dep-pre-bundle] Missing "./decorators" export in "lit" package

    node_modules/.pnpm/vite@2.9.7/node_modules/vite/dist/node/chunks/dep-88bd5805.js:39941:7:
      39941 │   throw new Error(
            ╵         ^

[karimayachi]

Same here (not using vite.js, but webpack).

Release 25.3 transpiled the imports including the .js extension, whereas 26 does not. Webpack 5 doesn't seem to like that. Haven't yet looked into if configuring webpack differently fixes this.

[asyncLiz]

Hi! Our library use bare module specifiers following TypeScript conventions, which restricts adding .js at the end of files (it is unneeded in TypeScript environments).

Adding .js breaks TS code completion internally, which is why we do not follow this specific lit convention.

We do not recommend deploying without a build system/bundling. Applications should use a build tool such as rollup or webpack with plugins that can handle the bare module specifiers.

[christophe-g]

Thanks a lot for your answer @asyncLiz

I shall be worried v0.26 is going to break build pipelines for many consumers of this library.

Applications should use a build tool such as rollup or webpack with plugins that can handle the bare module specifiers.

• vitejs - the frontend build tool that I reported to be using - is an build tool and handles bare module specifyer
• @karimayachi is using webpack

Our library use bare module specifiers following TypeScript conventions, which restricts adding .js at the end of files

lit/lit#1986 (comment)

Can you re-open the issue and propose a more helpful way forward ?

[karimayachi]

Hi @asyncLiz ,

Thanks for the reply. As @christophe-g mentioned, we are using bundlers. Webpack in my case and I believe Vite uses Rollup.

It's not the bare specifiers that are the problem (I use those all the time, and Webpack handles them great). Specifically it's about referencing specific files within a package:

Something like this:

import { RippleHandlers } from '@material/mwc-ripple/ripple-handlers'; // no problem
import { html, LitElement } from 'lit'; // no problem
import { eventOptions, property, query, queryAsync, state } from 'lit/decorators'; // problem

Before version 26 this was transpiled as:

import { RippleHandlers } from '@material/mwc-ripple/ripple-handlers'; // no problem
import { html, LitElement } from 'lit'; // no problem
import { eventOptions, property, query, queryAsync, state } from 'lit/decorators.js'; // no problem

Probably your upgrade to TypeScript 4.4.4 caused the change, but Webpack (latest) and probably other bundlers can't handle this.

If this is something that can be fixed on our side by changing the configuration of our bundlers, please point us in the right direction, otherwise please reopen this issue.

Kind regards,
Karim

[kaseyhinton]

I am using web dev server and have configured it with the proper flag for bare module resolution and it still doesn't work. I have also tried to get web dev server to use the Rollup plugin for module resolution and that did not work either. I have like 50+ applications that need to be locked into an older version of Mwc components if I can't find a way to get .26 to build.

[asyncLiz]

Thanks for the comments! We're looking into how to resolve this issue.

[AbandonedFridge]

@asyncLiz Thank-you. If it helps, the issue seems to be, at least for me, happening because the built .js files still contain the bare module specifier so Typescript(which likes bare modules) is done and out of the loop at the point when the bundler(in my case, rollup and @web/dev-server) tries to transform the modules.

I'm guessing both the built-in resolver and @rollup/plugin-node-resolver fail because, unless I'm missing something, basic and node-style resolution patterns only like bare modules when pointing to a module by package name or containing directory, not when referencing a module file directly. That seems to be a pretty typescript specific thing.

[christophe-g]

Thanks for the comments! We're looking into how to resolve this issue.

Thanks !

[sgammon]

hitting this in rollup and lit on the starter package, with no other added dependencies or tooling. has this essentially broken any use of lit with mwc at latest ? if so, what should we be using aside from lit?

[sgammon]

i.e. shouldn't this just be titled 0.26 does not build with lit? or is there a tooling change we can apply that works around this issue?

[tobiu]

just tested this inside the webpack based https://github.com/neomjs/neo build and it breaks.

will need to downgrade for now.

off topic: regarding "bare module specifiers" => it would be really nice if there was a version which would run as it is directly inside the browser. the entire neo dev mode can handle it, with the exception for your components, which have to get pulled in from a cdn.

[asyncLiz]

Fixed in v0.26.1

[tobiu]

this was fast. appreciated! (the neo build works fine again)

for the dev mode (no builds at all), i need to stick to a cdn which resolves the imports. e.g.:
https://unpkg.com/@material/mwc-textfield@0.26.1/mwc-textfield.js?module

a bit slow (could cache it inside a service worker).

[sgammon]

@asyncLiz thank you for the quick update!