Support thread loader by optional inline emitCss (base64, querystring)

[non25]

This option makes svelte-loader output base64'd css in querystring, which is always available to any thread.
It is turned off by default because it pollutes webpack's console output, but if user needs to use thread-loader, he can.

[benmccann]

Would this feature be useful in other cases? (e.g. I think you mentioned tailwind and babel). If so, can we describe this feature more generically? I'm find mentioning thread-loader, but it maybe shouldn't be the focus

[non25]

I can't think of other cases... It is mainly useful because it allows other processess/workers to get css reliably, and not try to access an empty Map.
The default Map storage with file paths in a query will only be accessible in that exact process.
@trash-and-fire told me that we can detect if thread-loader is used in a pipeline with svelte-loader and turn this on automatically.
Maybe we should make it that way.. 🤔

[benmccann]

That might be nicer than adding an option. But I also wonder if it's even worth adding something that's only useful for thread-loader

[non25]

Part of the reason I'm here is because one day one man tried to use svelte-loader with tailwindcss through svelte-preprocess and had 4 mins of build-time and 40 seconds of reload time for 20 or so components. 😁
That would save him.

[benmccann]

Does that mean that you need to use thread-loader to deal with sveltejs/svelte-preprocess#275 ?

[non25]

Exactly. It will speed up that thing significantly.
But you also need to configure preprocess and webpack .css pipeline correctly to gain maximum performance.

[trash-and-fire]

I think this is not an entirely accurate statement.

There was a problem of rebuilding all virtual css files if only one changed. This issue has been fixed without using a thread loader. A thread loader can provide additional performance by parallelizing the compilation of each file into a process pool. But there is no shared memory between processes, we must transfer all the content of the css file through the import line.

[non25]

Now it checks automatically. this.emitFile is not available in loaders spawned by thread-loader, so I'm using that.

[syvb]

Perhaps there should be an override to force inline mode to always be enabled or disabled? (this could be written as options.forceInlineCss ?? this.emitFile === undefined in Node 14+ but alas versions below that don't support the ?? operator)

Suggested change

	const threadLoaderUsed = this.emitFile === undefined;
	const threadLoaderUsed = (options.forceInlineCss === undefined) ? this.emitFile === undefined : options.forceInlineCss;

[benmccann]

It's a reasonable suggestion, but the downside is that the option then becomes part of the API, which makes it hard to change (we'd need another major release). I might wait until a need for it arises to leave us more flexibility instead of adding it up front

[non25]

So what do you think guys?
I think adding this feature could be helpful. In default webpack configs it won't do anything, but people can start to experiment with thread-loader and tailwindcss and try to get better results in dev mode cold starts and in prod mode.
If it would appear to be useless then we can safely remove it, because no API changes were made.

[non25]

Interesting, it doesn't work with svelte-preprocess. I decided to try it with my scss preprocessed project and it tells me this stuff:

Thread Loader (Worker 0)
ParseError: Unexpected input (19:22)
17:   .button {
18:     $bgcol: hsl(215, 35%, 50%);
19:     background-color: $bgcol;
                          ^
20:     border: pxrem(1) solid mix(#000, $bgcol, 14);
21:     border-radius: pxrem(5);

So I guess we will release without this PR.