Core: Provide a way to load Prism from inside a Worker without listen…

[Golmote]

…ing to messages.

This should fix #1059 and #1172.

Usage from inside a worker:

var Prism = {
	insideWorker: true
};
self.importScripts('prism.js');

Does that look good to you @ligaz @Rob--W @falsandtru?

I feel the naming is quite poor, but I couldn't come with any better name for this param.

[Rob--W]

LGTM. How about replacing insideWorker with a name that more accurately describes the purpose or effect of the option? E.g. disableMessageHandler: true?

[ligaz]

disableMessageHandler does not ring a bell to me what exactly it is supposed to do. insideWorker although not perfect makes more sense.

Other alternatives that I can come up with are: runInWorker, inWorker, or just worker, but I'm not sure they are better.

[Golmote]

@LeaVerou @zeitgeist87 Any advice on the naming? I'm receiving mixed signals there. :')

[LeaVerou]

Can't we autodetect this instead of requiring some special parameter? I believe worker environments can be detected, so why do we need this?

[Golmote]

@LeaVerou We must differentiate two cases where Prism might find itself inside a worker.

1. When Prism itself creates a Worker for async highlighting.
2. When the user decides to load Prism from inside a Worker.

The core autodetects when it's in a Worker, but it only handles case 1. We need a param to handle explicitely case 2, so that we can skip attaching the listener for messages.

[LeaVerou]

I see. Can we instead explicitly handle case 1 somehow? That way including Prism from a worker would just work without any special syntax, and we can use whatever special syntax we want inside Prism when we create the worker for async highlighting.
Not that I can think of a way to do this right now, but maybe you have an idea?

[Rob--W]

You could use `location.pathname` to test whether the worker script is loaded via importScripts. This "location" object is a WorkerLocation instance and only supported by recent browser versions. Perhaps you can use this to select a reasonable environment-dependent default, and allow users to override the default (e.g. if the option is not supported). Alternatively/additionally, detect the presence of the Prism global before the script has loaded. If it was set, then a script has run before the library was loaded, so you can then infer that `importScripts` had been used.

[Golmote]

@Rob--W Unless I missed something in your explanation, I can't see how this will help us differentiate when Prism is loaded as a worker and when it's loaded with importScripts. In both cases, location will be an instance of WorkerLocation, won't it?

@LeaVerou No, I can't think of any way to differentiate the two automatically.

[Rob--W]

@Rob--W Unless I missed something in your explanation, I can't see how this will help us differentiate when Prism is loaded as a worker and when it's loaded with importScripts. In both cases, location will be an instance of WorkerLocation, won't it?

In both cases location is an instance of WorkerLocation indeed. But that is besides the point. I explicitly referred to location as WorkerLocation to emphasize that this is a relatively new API, so that if you want to use it, then you'd better include a fallback in case the location global isn't available.

That having said, when loaded as a worker by Prism, location.pathname.endsWith('/prism.js') is most likely true (unless renamed). When loaded as a library, the condition is most likely false. This difference is how you can reasonably accurately guess whether Prism is used as a stand-alone worker, or as a library in a Worker.

[Golmote]

@Rob--W Oh, ok, I get it now. That's smart, I don't know if it's a reliable enough solution to be considered the default behaviour, though.
@LeaVerou Considering that loading Prism from inside a worker is probably an edge case already, I think requiring a manual configuration is not that annoying.

[LeaVerou]

Ok, I trust your judgement @Golmote :)
And you're right, I guess it's not that common.

[Golmote]

Ok, I went for the long explicit one: disableWorkerMessageHandler.