Closed FallingSnow closed 3 years ago
Possibly related changes to globalThis.location
: https://deno.land/posts/v1.7#add-support-for-codeglobalthislocationcode-and-relative-fetch
We have to figure out some way for the SSR part to basically run with --location
. This will need some more thought.
Removing the following seems to be working for the time being. https://github.com/alephjs/aleph.js/blob/0456c9da64ba09967a1b376358c93e8991bdff97/project.ts#L620-L633
Yeah it prob should work, but I feel like we should look into changing how we do SSR right now. Currently we use a fork of Deno DOM, but as @ije said, we should try avoiding use of deno dom to polyfill everything.
Okie.
I do feel if this doesn't break anything and does solve the issue, this or another fix should be added. Would be a bummer if someone came along with everything up to date and aleph fails.
I don't know for sure but I think the new compiler is changing the way we do SSR
@FallingSnow you are right, i think we can use Object.defineProperty
to hack deno's limit.
ensure we can get a right location
object in SSR, even i don't recommend to access it.
@FallingSnow you are right, i think we can use
Object.defineProperty
to hack deno's limit.
It doesn't seem like that is possible
ok, i'm going to remove all the browser polyfill objects: https://github.com/alephjs/aleph.js/pull/28/commits/068062fb94e9b08fafd6d23e42b35ab9d317b0a3
i just released an alpha version, now it should work in deno 1.7:
deno install -A -f --location=http://localhost -n aleph https://deno.land/x/aleph@v0.3.0-alpha.1/cli.ts
Just in case, someone will surf for latest 2021 issue... I got deno v1.10.1
and aleph v0.3.0-alpha.33
and initial installation was as:
deno install --unstable -A -f -n aleph https://deno.land/x/aleph@v0.3.0-alpha.33/cli.ts
And then executing aleph dev
(project created from aleph init hello_alpha_33
) I got:
ERROR invoke API: ReferenceError: Access to "location", run again with --location <href>.
at get (deno:extensions/web/12_location.js:365:17)
at createStorage (deno:extensions/webstorage/01_webstorage.js:91:28)
at localStorage (deno:extensions/webstorage/01_webstorage.js:178:24)
at handler (file:///...MY../.aleph/development/api/counter/index.js#9786cc:2:28)
at Server.handle (https://deno.land/x/aleph@v0.3.0-alpha.33/server/server.ts:189:21)
Note: localhost:8080 worked/running well.
I got some reading here and this issue last comment got me a hint, so I re-installed aleph:
deno install -A -f --location=http://localhost -n aleph https://deno.land/x/aleph@v0.3.0-alpha.33/cli.ts
And now aleph dev
is "clean".
Not yet sure, if --unstable
matters here.
@alundiak That is already a problem that has been reported, though an issue has not been made. Could you create one so it could be tracked somewhere else?
@shadowtime2000 I wanted to avoid duplication, I've already seen a few similar issues and PRs. So I will not create a new one. Unless it will appear again with deno 1.11.x
for example in future.
@alundiak I mean like, commenting on a dead issue that was resolved months ago doesn't really help avoid duplication lol. but okay.
the old aleph upgrade
command didn't add the location
flag that is used by the latest example app in api, i will improve the upgrade command for bootstrap options changes, deno run -A https://deno.land/x/aleph/install.ts
can work fine
See https://github.com/denoland/deno/issues/4981#issuecomment-685205034