lit-element with scss

[klemenoslaj]

I think the title explains what I am about to ask.

lit-element works great out of the box. I can pair it with JS or TS and all works well.
I wonder what would I require to compile scss instead of using pure css with lit-element?

[mischnic]

I'm not familiar with lit-element, but I think you want to compile SCSS and get the result as a string inside JS? (If not, please give an example of what you're trying to achieve).

With Parcel 2, you can do this out of the box (the example at the very bottom uses native html custom elements which should be rather similar): https://parcel2-docs.now.sh/getting-started/plugin-config/#predefined-(offical)-named-pipelines

[mischnic]

I tried installing config-default on my own, but that didn't help.

That's very strange. Do you have time to create a repo where this happens?

Is it possible for me to write my own transformer that uses scss transformer and outputs something like this:

Yes. It would be conceptionally be similar to how inline CSS style stags are transformed:
<style> some code </style> is turned into <style>some_random_hash</style> and then later on the packager replaces this with the bundle contents.

So your transformer would return additional assets (one per css template string) where isInline: true and with a uniqueKey (e.g. one counter per file) and the contents (<CSS CONTENT FROM SCSS>). Then you need to replace <CSS CONTENT FROM SCSS> in the JS Asset with the return value of asset.addDependency(theUniqueKeyFromBefore) (some_random_hash from before). The default JSPackager should then replace the hash without any changes. (We will have docs for writing plugins very soon, I'll make sure to add a section about how inline bundles work.)

[klemenoslaj]

That's very strange. Do you have time to create a repo where this happens?

Sure, I'll make one tomorrow. Will try to reproduce it on a clean setup, just to eliminate the additional possibilities of failure. I wonder if .parcel-cache could be corrupt tho, as I do not recall deleting it, but I did delete it later.

Yes. It would be conceptionally be similar to how inline CSS style stags are transformed:

Awesome! I will try to come up with something then. Looking forward to dig into parcel - it's amazing, good job guys 👍

[klemenoslaj]

Ok I just tried to reproduce this situation in a clean repository. While I succeeded it seemed to have been fixed after I removed node_modules and .parcel-cache and reinstalled.

Worth mentioning I am using yarn. Could it be that your auto-installation process messes up something?

---

Next thing I noticed, @parcel/transformer-react-refresh-babel got installed even though there is no notion of react in my setup? Expected?

---

Side question: did you consider batching all the installations into one?

[mischnic]

Next thing I noticed, @parcel/transformer-react-refresh-babel got installed even though there is no notion of react in my setup? Expected?

Yes, it's part of the default config so that React HMR works without a custom config.
It's however a noop if you don't have react in your package.json dependencies:

parcel/packages/transformers/react-refresh-babel/src/ReactRefreshBabelTransformer.js

Line 16 in d33fcd9

return !(pkg && pkg.dependencies && pkg.dependencies['react']);

Side question: did you consider batching all the installations into one?

That does make sense, but it's also possible that there is a chain of autoinstalls (so a second autoinstall is only triggered after the first one finished and the code that used the package ran - e.g. a pug file that includes a scss stylesheet).

[klemenoslaj]

That does make sense, but it's also possible that there is a chain of autoinstalls (so a second autoinstall is only triggered after the first one finished and the code that used the package ran - e.g. a pug file that includes a scss stylesheet).

Ok, that makes it more complex unless there is a way of predicting the chain.

---

I pushed my repo anyway: https://github.com/klemenoslaj/parcel-nightly-test

Please note it is without yarn.lock intentionally so the installation process goes from beginning if you try it out. As well leaves room to test npm too without compatibility issues of some sorts.

Another thing...after manual reinstallation the config default error is gone, however the error of fHost appears. That's due to transformer-typescript-tsc version 2.0.0-alpha.3 being installed automatically instead of nightly-277. installing nightly-277 manually resolves this.