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

Webpack-related build error #234

Open
username227 opened this issue Nov 1, 2024 · 14 comments
Open

Webpack-related build error #234

username227 opened this issue Nov 1, 2024 · 14 comments
Labels
fix-committed Fix for the issue is in the main branch

Comments

@username227
Copy link
Contributor

username227 commented Nov 1, 2024

Hi, someone alerted me on the AUR page that it is failing to build. I was able to replicate both from the AUR package and building manually. This only cropped up sometime AFTER you released the latest stable version. I do believe that it is probably related to a recent update on a dependency. If I had to guess, I would say that it is probably related to the nodejs update to 23.1 on October 25th, but you would probably know better than me. This is the output I get from the build command:


> [email protected] build
> tauri build -b

     Running beforeBuildCommand `npm run webpack-prod`

> [email protected] webpack-prod
> webpack --config webpack.prod.js

[webpack-cli] Failed to load '/home/jerry/TrguiNG/webpack.prod.js' config
[webpack-cli] Error: require() cannot be used on an ESM graph with top-level await. Use import() instead. To see where the top-level await comes from, use --experimental-print-required-tla.
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:365:17)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:325:47)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1396:24)
    at Module._compile (node:internal/modules/cjs/loader:1529:5)
    at Object..js (node:internal/modules/cjs/loader:1678:16)
    at Module.load (node:internal/modules/cjs/loader:1315:32)
    at Function._load (node:internal/modules/cjs/loader:1125:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:216:24)
    at Module.require (node:internal/modules/cjs/loader:1337:12) {
  code: 'ERR_REQUIRE_ASYNC_MODULE'
}
       Error beforeBuildCommand `npm run webpack-prod` failed with exit code 2
@qu1ck
Copy link
Member

qu1ck commented Nov 1, 2024

Yes, this is most likely related to node 23, see more here
https://medium.com/@michauwybraniec/node-23-update-potential-future-backward-compatibility-issue-with-top-level-await-in-node-js-c7c123c98049

I don't use require() anywhere in my code so the issue is likely in one of the dependencies. Can you run webpack with --experimental-print-required-tla as suggested in the error message to see where the offending code is?

@username227
Copy link
Contributor Author

OK no matter what I try I get the same error loading config. can you be more specific with the commands I need? thanks.

@qu1ck
Copy link
Member

qu1ck commented Nov 1, 2024

Run
NODE_OPTIONS='--experimental-print-required-tla' npm run webpack-prod
from the root of the repo

@username227
Copy link
Contributor Author

OK:

Error: unexpected top-level await at file:///home/jerry/TrguiNG/webpack.common.js:29 const tsConfig = JSON.parse(await readFile("./tsconfig.json"));

@username227
Copy link
Contributor Author

username227 commented Nov 1, 2024

Any changes you make will fix the manual build, and it will git the -git package but will not fix the regular trgui-ng arch package as it will pull up the last release. You will either have to put out a new release, OR I can make a patch downstream to patch the code prior to build which would fix it downstream until you're ready to make a new release. Just let me know. However, I am not sure how such a patch would affect the automatic AUR update you have going.

qu1ck added a commit that referenced this issue Nov 1, 2024
For some reason node insists on loading them as commonjs despite
"type": "module" in package.json. This leads to import errors
in node 23.

Issue #234
@qu1ck
Copy link
Member

qu1ck commented Nov 1, 2024

I pushed a fix. There is something funny going on with module type detection and I suspect node is not behaving according to it's spec but I don't have a lot of time to dig deep and the workaround I pushed is good enough.

If you can add a patch that uses the commit above that should fix it until next stable release. For next release patch will not be needed, my ci job will work fine, we will probably just have to remove the no longer used patch file manually.

@username227
Copy link
Contributor Author

OK. I will test n ow and work on a patch tomorrow night, don't have time today.

@username227
Copy link
Contributor Author

Yes, it works now. thanks! I'll be in touch later tomorrow night.

@username227
Copy link
Contributor Author

OK I patched it quickly now. Pushed to AUR. Please note that when I reran the shasums for the pkgbuild, it now calculated a shasum for the git repository itself, whereas before it was set to 'SKIP'. We might need to manually switch it back to skip; but, if you can make it so that the shasums auto-update as well, then that would be even better.

@qu1ck
Copy link
Member

qu1ck commented Nov 1, 2024

I am not sure how to calculate sha sum of a whole repo. Is it done by some arch specific tool?

@username227
Copy link
Contributor Author

that, my friend, is a good question. When we first made the package, it was coming up as 'SKIP' so it might be a relatively new thing.

I will try to ask in some arch-related forums next week and get back to you.

I do know that if you add a github page to the sources of a pkgbuild but don't remember to put git+https in front of it, it will download it as a file, not a directory; perhaps it has something to do with that.

@qu1ck
Copy link
Member

qu1ck commented Nov 1, 2024

Yeah looks like a new thing:
https://www.reddit.com/r/archlinux/comments/1bjruqq/question_about_sha256sums_in_pkgbuild/

I'm not sure it's worth the effort to run in ci job. If we do nothing it will just go back to SKIP.

@username227
Copy link
Contributor Author

it'll either go back to skip or it'll have a mismatch that needs to be manually switched back to skip, not sure which one.
I'll leave that to you. There are probably some arch purists that won't like it, but I personally don't fully see it as being a huge deal either.

@qu1ck
Copy link
Member

qu1ck commented Nov 3, 2024

It will go back to skip, that's what is in our template https://github.com/openscopeproject/TrguiNG/blob/master/ci/generate_pkgbuild.py#L39

@qu1ck qu1ck added the fix-committed Fix for the issue is in the main branch label Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix-committed Fix for the issue is in the main branch
Projects
None yet
Development

No branches or pull requests

2 participants