deno_core Extension with Global Access
Is there a way to make a Deno Extension be accessed by
Extension.op()
instead of Deno.core.ops.op()
?38 Replies
Does this work?
Of course that does work, but that'd require asking everyone to add that, I'm looking for a way to make it so whenever
deno_core::JsRuntime::execute_script
is run, it'll just work.currently it's not possible OOTB, you need to handle it yourself
So how do extensions like
console
and fetch
have their stuff globally?
I'm willing to add a JS file to the extension.the global scope is assembled in a file called
99_main.js
that is executed after all extensions have been loaded and added their relevant stuff to different window.__bootstrap
namespacesSo is there no way to implement a similar functionality as that into my own project without forking?
you certainly can, which crates do you use? do you use
deno_runtime
crate?Yes, runtime.
if you use
deno_runtime
it will be harder right now - @crowlkats and I are working on a PR that will make it much easier (https://github.com/denoland/deno/pull/16597) that will allows to extend global scope as you see fitall in all you should still be able to assign whatever you want to
globalThis
after all JS code from crates executesWhat's the goal for that pr? (If any)
to allow creating V8 snapshots from existing V8 snapshots
so you can extend what's already in
deno_runtime
and change it as you see fit
mainly useful for a windowing project Leo is working onAround how long should I expect to wait for that
a week probably
So next patch?
Alright. I appreciate all of this work. Thanks for the knowledge.
yes, next patch release
@.bartlomieju i see it was released, how would i properly add to the globalThis?
@crowlkats can you give a quick rundown?
a live example of this is the cli in the deno repo.
first is the build script:
first off you need to define a path for the snapshot and path for where you have your js files
https://github.com/denoland/deno/blob/main/cli/build.rs#L460-L463
and then the actual snapshot creation
https://github.com/denoland/deno/blob/main/cli/build.rs#L271-L317
then you need to get the snapshot during execution https://github.com/denoland/deno/blob/main/cli/js.rs and pass it to your
WorkerOptions
's startup_snapshot
.
then, in a js file in the folder you defined as js folder you do whatever you need to do, inside the usual iief; at the end of the iief you add to the global scope whatever you want with window.__bootstrap.globalScope.windowOrWorkerGlobalScope.myThing = myThing
can this be done with extensions instead of everything in the build.rs? I dont exactly follow correctly
I am not sure I understand
How would I do this with an extension? Do I have to put everything in the js folder, or can I integrate extensions into this as well?
ah, at the time it wasnt possible, but now it is
i can write you up how in a bit
Could I have this please?
my bad, forgot about it. will do it now
Thank you 😄
sadly there is no live example.
first instead of doing https://github.com/denoland/deno/blob/main/cli/build.rs#L474-L475, just use a vec with
deno_runtime::js::get_99_main()
in it.
Then, in deno_core::snapshot_util::CreateSnapshotOptions
there is a new field called extensions_with_js
; to that you pass a vec of extensions you want to use to add additional js files.
that should be allIf I want all the default extensions in the cli, would I have to add those myself?
hmm
@crowlkats it errors out if you leave extensions as a vec. Is this intended?
It seems you have to include every single extension the runtime uses for a successful build. Seems kinda frustrating, and would make maintaining the list frustrating.
unsure how we could improve that really
@.bartlomieju thoughts?
I mean it wouldn't be challenging to add all the extensions to my project, it's just maintaining that list would be frustrating.
The only solution I could think of for improving maintainability is making a function to get all default extensions built into deno_runtime, but that seems like an unnecessary solution to something that isn't much of a problem.
Yet again, the cli also includes all those extensions, so a function would allow one list for the runtime and cli to use. runtime build script cant access runtime nvm
well we had this one idea, that each
Extension
would specify its name in the builder and then we could add .depends_on(&["name1", "name2"])
and panic if one of the extensions hasn't been yet registered
that would make debugging problems much easier in such caseah yea, though that still seems not perfect
maybe make a function that returns a vec of extensions in deno_runtime?
that's also an option
That was the idea I had, but unless you want to do that in deno_core or made a new package for that, you couldn't access it in the runtime build script
yea thats the one problem with it...
though would still be better than nothing
The only that would work with everything would be to create an ext module that re-exports everything but I don't see that being a good solution to a small problem
Also, any specific reason why runtime defines all the default runtime extensions as
extensions_with_js
instead of just extensions
like in the cli?Yes, if you put them in
extensions_with_js
the JS code defined in extension will be executed, it only need to happen once so that why they are passed in extensions
in the cliah
it works but it looks like it'd be annoying to maintain