Skip to content
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

Swap node internal packages out for fetch in Resource #11773

Merged
merged 4 commits into from
Jan 22, 2024
Merged

Conversation

jjspace
Copy link
Contributor

@jjspace jjspace commented Jan 18, 2024

Description

Working on updating cesium-webpack-example and creating cesium-vite-example I realized there are 2 main sticking points to using Cesium in various JS build environments.

  1. Copying the required static files for workers (Inline Static Assets in Builds #10619)
  2. Marking select node modules as external, http, https, url and zlib, which are only used in Resource.js when on node

This PR aims to remove that second point by swapping out the "node only" logic for fetch() which has been enabled by default since Node v18.

As far as I can tell I was able to mimic the existing behavior except for one issue with an error that's thrown. There's currently no Specs set up for running in a Node environment so running the smoke screen tests Specs/test.cjs and Specs/test.mjs was the only way to verify and that works correctly.

I'd really appreciate more eyes on this as I know Resource is a fairly core class to cesium and I don't want to negatively impact anything.

Issue number and link

No issue

Testing plan

  • run node Specs/test.cjs
  • run node Specs/test.mjs

Author checklist

  • I have submitted a Contributor License Agreement
  • I have added my name to CONTRIBUTORS.md
  • I have updated CHANGES.md with a short summary of my change
  • I have added or updated unit tests to ensure consistent code coverage
  • I have update the inline documentation, and included code examples where relevant
  • I have performed a self-review of my code

return new Uint8Array(loadWithHttpResponse).buffer;
}
}

function loadWithHttpRequest(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The data and overrideMimeType arguments are not used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is intentional. They were not used before and I aimed to preserve the existing behavior as close as possible.

I don't know exactly why they weren't used in the first place or why this only transforms text and json but the goal of this PR was not to re-write the capability of this function; just swap out the components it uses to make building easier.

responseHeaders[key] = value;
});
deferred.reject(
// TODO: there is not directly equivalent to http.IncomingMessage, is the full obj ok as the second arg here?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a problem in RequestErrorEvent -- the second argument is simply reported

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no actual problem with the way RequestErrorEvent is used. The problem may arise downstream with someone consuming that value which has now changed. Given that it's in the error after something already failed I'm not sure how much it actually matters.

Open to thoughts @jjhembd @ggetz

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If something is changed for the downstream user, it should be noted in CHANGES.md.

Copy link
Contributor

@jjhembd jjhembd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jjspace! This looks like a nice cleanup.
I just have a couple minor comments in the code. Also, can we now update build.js and gulpfile.js to not declare zlib and url as external?

Copy link
Contributor

@ggetz ggetz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jjspace! As for a testing plan, based on the original PR where NodeJS compatibility was added:

I tested using sampleTerrain using a node.js application, which is the main reason I made this change.

So the test.*js test cases are likely a good candidate for whether or not this is working as needed.

Potentially, another node script which load a 3D tileset and checks some basic properties may also be a good use case.

Specs/test.cjs Outdated Show resolved Hide resolved
@jjspace
Copy link
Contributor Author

jjspace commented Jan 22, 2024

@ggetz @jjhembd updated with pr comments. I wasn't sure if this counts as a breaking change or not but put it under that category anyway because it does affect build tools. I will plan to update our examples after this is merged and released.

@ggetz
Copy link
Contributor

ggetz commented Jan 22, 2024

Thanks @jjspace! I'll take a final pass on this shortly.

I wasn't sure if this counts as a breaking change or not but put it under that category anyway because it does affect build tools

I agree this counts as a breaking change and should be listed as such.

@ggetz
Copy link
Contributor

ggetz commented Jan 22, 2024

Looks good @jjspace. I have tested the packed npm module locally as well. Everything is working as expected!

@ggetz ggetz merged commit 3ca3506 into main Jan 22, 2024
9 checks passed
@ggetz ggetz deleted the resource-fetch branch January 22, 2024 21:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants