-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
patch(): node build follow up #8652
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cleanUpJsdomNode
=>getEnv().dispose
getEnv().window
=>getWindow
getEnv.document
=>getDocument
- refactor WebGLProbe and expose NodeGLProbe (a stub) on env
- remove
isLikelyNode
: tests useisNode()
- remove
setEnvForTests
=> usesetEnv
directly
Build Stats
|
src/env/node.ts
Outdated
@@ -20,31 +20,37 @@ const { window: virtualWindow } = new JSDOM( | |||
FetchExternalResources: ['img'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is needed, it seems to be a relic of the past
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it could still be needed to actually load base64 images.
Since canva is not mandatory for jsdom, loading images is completely optional.
That is my understanding, if you want them to actually be loaded, you have to ask for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is dead.
Not typed and I searched the repo and couldn't find it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes is not more there indeed.
It is replaced by resources 'usable' we have below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thing I held back and waited with all this
A lot of ink for very little change, basically a no brainer, a cleanup task
export const setEnvForTests = (window: Window) => { | ||
env.document = window.document; | ||
env.window = window; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was specific for tests, for now setEnv is a necessity of delaying an import / definition issue, and i don't think it is a feature yet. I would like this to stay setEnvForTests ( and even that was some kind of issue of testing and not a real need ) and setEnv to not be exposed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking we should expose setEnv
for devs who work on a strange env, someone wrote about it in #8208
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in case we will have specific pr with new feature for it after evaluating which are the side effects.
src/filters/GLProbes/WebGLProbe.ts
Outdated
if (getEnv().isLikelyNode) { | ||
return; | ||
} | ||
queryGL() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why renaming WebGL to GL?
queryWebGL is meant to detect support for WEBGL, i think the old name is good.
GLPrecision change i think is ok, since the constant is stil GL_PRECISION_XXXXX in the WEBGL api.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because I saw there is support for GL on node canvas...
so a dev could somehow wire it up with fabric and use a NodeGLProbe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyways since we need a probe for node I had to rename the base class/folder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The npm module is called gl
but is still the WebGL specs api.
Seems all good to me, apart some naming issues. |
How? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remaining
- GL naming
- setEnv for tests
apart that is good to go
You can change as you see fit and merge
This PR introduces a circular dependency. |
let me look |
@@ -82,7 +82,7 @@ var virtualWindow = new jsdom.JSDOM( | |||
resources: new CustomResourceLoader(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need this?
Is just a console log...
And then we don't need to reconfigure the env so we won't need to expose setEnvForTests as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we won't need to expose it in fabricJS, nor remove it, we will probably be able to import it directly from the build folder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean we don't need this configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CustomResourceLoader justs log to console a line
It is meaningless
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we can use the node env from fabric w/o this headache
Regarding the import cycle |
yes is not an issue right now we just need a way to detect them properly |
OR we can make initFilterBackend async and do a dynamic import of the GLProbe depending on getEnv. |
That is wrong! Since then we init the browser env at import time |
We can safely use |
we will find a solution, the unbundle import is just a playground now, and is node only, so not an issue. |
…c env dispose ( instead of cleanup JSDOM ) (#8652)
Motivation
Follow up #8632
Description
The dirty part of #8632
Changes
cleanUpJsdomNode
=>getEnv().dispose
getEnv().window
=>getWindow
(done for ease of coding, finding etc. and one day perhaps when we split browser logic we can use window directly since there really is no use for it in node)getEnv.document
=>getDocument
(same)isLikelyNode
: tests useisNode()
defined in config filessetEnvForTests
=> usesetEnv
directlyGist
In Action