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

Feat proposal enable fetching external resources using native fetch API in Node.js version 18 later #935

Merged
merged 11 commits into from
Sep 26, 2022

Conversation

takurinton
Copy link
Contributor

@takurinton takurinton commented Sep 18, 2022

I've defined globalThis.fetch at #934, but currently wmr can't access external resources when use prerender mode.
Therefore, I came up with a plan to make fetch available natively in Node.js 18 and later.

But Node.js 18 is not LTS yet, what do you think?

@changeset-bot
Copy link

changeset-bot bot commented Sep 18, 2022

🦋 Changeset detected

Latest commit: 7c1bb6c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
wmr Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR


const nodeVersion = process.version;
const isNodeVersionOver18 = Number(nodeVersion.split('.')[0].slice(1)) >= 18;
if (isNodeVersionOver18) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is there a way to run tests on multiple versions?

Copy link
Contributor Author

@takurinton takurinton Sep 18, 2022

Choose a reason for hiding this comment

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

Oh, and two versions, 12 and 14, are running now. This felt like a no problem in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm also considering breaking down this test.

Instead of branching using if in one test, write a test for Node.js version 17 or less and a test for Node.js version 18 or more, and skip if the version is not applicable. I think it is also possible.
This part is one of the things I want to discuss in this PR.

Copy link
Member

Choose a reason for hiding this comment

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

Instead of branching using if in one test, write a test for Node.js version 17 or less and a test for Node.js version 18 or more, and skip if the version is not applicable.

I like this idea. There's slightly different behavior between the two that (ideally) we'd test.

We can definitely alter the CI config to cover newer versions of Node.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I completely forgot about this.
Last time I called fetch without the leading slash here, but this test does not work with the regex changes you reviewed.
https://github.com/preactjs/wmr/blob/main/packages/wmr/test/fixtures/prerender-resource-fetch/index.js#L2

I think to need to modify the test here as well. I think the comments here will be helpful for that.
#935 (comment)

Copy link
Contributor Author

@takurinton takurinton Sep 22, 2022

Choose a reason for hiding this comment

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

Oops, no correction of above comment was necessary.

@takurinton takurinton changed the title WIP: enable fetching external resources using native fetch API in Node.js version 18 later Enable fetching external resources using native fetch API in Node.js version 18 later Sep 18, 2022
@takurinton takurinton marked this pull request as ready for review September 18, 2022 20:21
packages/wmr/src/lib/prerender.js Outdated Show resolved Hide resolved
packages/wmr/src/lib/prerender.js Outdated Show resolved Hide resolved
packages/wmr/src/lib/prerender.js Outdated Show resolved Hide resolved
@takurinton
Copy link
Contributor Author

takurinton commented Sep 22, 2022

TODO: will fix test
I'm going to work!
I will write this PR when we come back!

Comment on lines 125 to 133
// @ts-ignore
globalThis.fetch = async (url, options) => {
if (pattern.test(String(url))) {
return localFetcher(url);
}

console.warn(`fetch is not implemented in Node.js, please upgrade to Node.js 18 or above`);
// When fetching an external resource, it returns the native fetch API
// though `fetcher` function is an alias created to avoid infinite loops
return fetcher(url, options);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

overrided globalThis.fetch with our own implementation.
ref #935 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The fetcher function is an alias function defined to avoid infinite loops and is equivalent to the native fetch function.

Copy link
Contributor Author

@takurinton takurinton Sep 22, 2022

Choose a reason for hiding this comment

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

When Node.js version 18 later, I addressed this by writing conditional expressions for both fetch is defined and it is undefined to override.
I also wrote corresponding tests.

Local fetching should now be automated. If you expect a different behavior from the fetch that wmr itself is overriding, you should be able to solve this by writing the following code.

export async function prerender(vnode: VNode) {
    globalThis.funkyFetch = ...
}

const fetcher = typeof window === 'undefined' ? funkyFetch : fetch;
fetcher(...);

@takurinton takurinton changed the title Enable fetching external resources using native fetch API in Node.js version 18 later Feat proposal enable fetching external resources using native fetch API in Node.js version 18 later Sep 22, 2022
@takurinton
Copy link
Contributor Author

After merging 936 into main, follow this branch as well and run the test

Comment on lines +106 to +133
// When Node.js version under 17, native fetch API undefined
// So it will give a warning when the syntax to retrieve the file and the url is passed
// @ts-ignore
globalThis.fetch = async url => {
if (pattern.test(String(url))) {
return localFetcher(url);
}

console.warn(`fetch is not defined in Node.js version under 17, please upgrade to Node.js version 18 later`);
};
} else {
// At that time, implement using reassignment to avoid entering an infinite loop.
const fetcher = fetch;
// @ts-ignore
delete globalThis.fetch;

// When Node.js version 18 later, native fetch API is defined
// Override with own implementation if you want to retrieve local files in Node.js 18 later
// ref https://github.com/preactjs/wmr/pull/935#discussion_r977168334
// @ts-ignore
globalThis.fetch = async (url, options) => {
if (pattern.test(String(url))) {
return localFetcher(url);
}

// When fetching an external resource, it returns the native fetch API
// though `fetcher` function is an alias created to avoid infinite loops
return fetcher(url, options);
Copy link
Member

Choose a reason for hiding this comment

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

The comments explaining the workflow here are excellent! Really good stuff.

@takurinton
Copy link
Contributor Author

@rschristian
Currently the tests running on CI are failing, but I have tried locally on my own and they seem to be unstable as well.
Does this work in your environment??

(We've talked about tests being unstable before..)

packages/wmr/test/production.test.js Outdated Show resolved Hide resolved
packages/wmr/test/production.test.js Outdated Show resolved Hide resolved
packages/wmr/test/production.test.js Outdated Show resolved Hide resolved
packages/wmr/test/production.test.js Outdated Show resolved Hide resolved
@rschristian
Copy link
Member

@takurinton Hmm yeah that's a weird error in the CI. Will look into it. Not sure if it's unstable or just something odd has broken.

Are you using 18 locally? Do the tests sometimes pass?

@takurinton
Copy link
Contributor Author

Are you using 18 locally?

yes, I am using v18.9.0

% node -v
v18.9.0

Do the tests sometimes pass?

Only the ● production 'demo app' should serve the demo app test fails every time. Other than that, it works sometimes.

@rschristian
Copy link
Member

Yeah that's the really weird error. Can't find the entry module, wonder if the resolution changed or something in Node 18.

Thanks for the extra info, that help me later. We won't block your PR on that working though, as it's outside your changes here so don't worry about those failures.

@takurinton
Copy link
Contributor Author

test name fiexd!!!

Thanks for the extra info, that help me later. We won't block your PR on that working though, as it's outside your changes here so don't worry about those failures.

Thanks!!! I'm relieved it's outside the scope of my implementation this time around!
But I'm curious about this issue and will work on it when I have time!

Copy link
Member

@rschristian rschristian left a comment

Choose a reason for hiding this comment

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

Looks good to me, thanks!

@rschristian
Copy link
Member

I'm not confident this is a test issue we can ignore. Earlier I misinterpreted one of our tests as being an error when it wasn't. Haven't used this in so long I forgot what our tests were doing.

The tests pass on the main branch and they're now running with Node 18 due to your earlier PR. If you are in fact seeing a test fail every time, I think it's an issue with this PR.

@takurinton
Copy link
Contributor Author

@rschristian
The test on the main branch is dry run because there are no changes in the actual code.
I think the way to find out if this is really a problem with this branch is to rerun the test in another PR or create a new one to see if this is the case.
What do you think?

@rschristian
Copy link
Member

Oh shoot. Yep, you're right. Sorry about that.

I'll spend some time tracking this down when I can. Would like to cut a release afterwards but wouldn't want to do that if there might be issues (related to this or not).

@takurinton
Copy link
Contributor Author

I am also trying to fix a few things about my demo app test failing.
Locally it fails because the .cache directory does not exist at my end, but in CI it fails because the dist directory does not exist.
And while I can just ignore the .cache directory with error handling if it doesn’t exist, I can’t proceed to the next process if I can’t get the dist directory.

For example, I can ignore the absence of a .cache directory by writing code like this in my local tests. (However, this is not where CI fails, so it is practically a meaningless workaround.)

await loadFixture('../../../../examples/demo', env);
// Often an error occurs here where the directory does not exist
// If the directory does not exist, skip `rmdir` and continue
for (const d of ['dist', 'node_modules', '.cache']) {
	try {
		await fs.rmdir(path.join(env.tmp.path, d), { recursive: true });
	} catch (e) {
		console.error(`skip removing. Because ${e.message}`);
	}
}

The actual log of the test looks like this.

local test

● production › demo app › should serve the demo app
ENOENT: no such file or directory, stat ‘/path/to/demo/.cache’

CI test

● production › demo app › should serve the demo app
ENOENT: no such file or directory, stat ‘/tmp/tmp-2076-LY3Agd84WR82/demo/dist’

This test is not compatible or reproducible locally and on CI, very difficult...

@takurinton
Copy link
Contributor Author

I'll spend some time tracking this down when I can. Would like to cut a release afterwards but wouldn't want to do that if there might be issues (related to this or not).

Thank you.
I agree with that. It is very difficult to find a drop-off point.
The test was unstable to begin with, but I am afraid that this release will have an impact.

@takurinton
Copy link
Contributor Author

@rschristian
I created another PR and ran the test on GitHub Actions and it failed in the same way.
I still can't be certain that the fetch change has no impact, but at least it appears to have no impact.

You can see log here.
https://github.com/preactjs/wmr/actions/runs/3111711765/jobs/5044311973

@rschristian
Copy link
Member

Seems pretty stable to me, see #938.

Definitely not from the fetch impl

@takurinton
Copy link
Contributor Author

@rschristian
I also feel that the fetch implementation is fine, as I wrote an exception in the fs.rmdir location in #937 and it stabilized!
#937 has been closed

@takurinton
Copy link
Contributor Author

All tests passed!!!

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