lit-html has no production dependencies directly, but it does depend on the availability of browser APIs. It uses the DOM API, and needs in particular the Template Element in order to function. It is possible that you can use JSDOM to provide these APIs.
Since lit-html is a DOM rendering engine, what use do you have for it that you want to use it in a JavaScript runtime that has no native DOM support? I'm interested in deno myself, so I'm curious to what your use case is here.
I should have been more clear: my concern isn't with running lit-html inside deno, but serving a lit-html-powered front-end (static assets as well as developer templates) from a deno server. Since deno apps have no package.json, and there's no equivalent to something like Webpack, I wonder how much work would be needed to make lit-html apps servable from deno.
This seems like either: 1) more of a deno question. 2) Not an issue.
lit-html is distributed on npm and can be installed locally with npm, or off a npm-CDN like unpkg.com. Aside from npm being a node program, nothing in lit-html runs on node and you could serve lit-html resources from any server running on Java, Python, Go, Brainfuck or whatever.
So basically... just npm i lit-html and you get your files. It doesn't matter if deno doesn't read a package.json.
Curious about any new potential interests in reviving idea. Since deno's compiler supports the dom library, I'm considering using deno as a high performance just-in-time compiler (not a runtime) for typescript in an Electron app. It can also simultaneously serve as a complementary runtime to the node runtime inside Electron.
The idea is to ship lit-html elements in *.ts files. When user first launches the app, deno will compile and cache the *.js output. The goal is to completely eliminate the build/bundling step. The source code can be pushed to CDNs like pika and be directly consumed by end users.
It's a very experimental idea but if it works, it would make lit-html so much easier to develop with.
I would strongly recommend against bundling the typescript compiler in either applications or tools like Deno, ts-node, etc. For applications, why would you have each user compile the typescript rather than doing it once before publishing? That's just wasted work. For tools you end up typing the major version to the latest version of TypeScript, which can and does have breaking changes on nearly every release.
As for lit-html and Deno: we publish standard ES2017 and depend on browser APIs. If your environment supports those, you should be good to go.