Eh, easier said than done. But if someone can figure it out, Iād love to see it.
1 Like
I cannot figure out how to make a small reproduction of this but I am getting a few weird cases with dynamic imports
I have this line of code somewhere:
const module = await import("path to my file");
And I was getting āReferenceError: Cannot access āmoduleā before initializationā
Which didnāt make any sense.
If I change the variable name to
const myModule = await import("path to my file");
This issue goes away.
If I try to make a small reproduction of this I canāt get the same error so if anyone has a clue on what the root cause is, I can probably work on a simple reproduction, but this was a super weird bug that popped up.
I also had an issue where:
return import(`../../strings/es/index`);
Failed to import anything but
return import("../../strings/es/index");
Worked just fine. So there is something funky going on with dynamic imports, but I really canāt make sense of it.
āThe module object is part of the CommonJS module systemās API, providing access to information about the current module and, most importantly, the exports property for defining what the module exposes.ā
const module = await import("path to my file");
const modules = await import("path to my file");
The code snippet also marks these 2 above as different CommonJS key words. This might be the cause.
I believe backticks are not accepted in imports because they imply a calculation of the path. Although you provide a string, the way it works is ā¦ look, let me calculate what the inside of the backticks gives so, here is your string. Backticks are used for dynamic strings such as `Here is my ${x.string}.` But, as I said, imports do not support dynamic paths because all imports and references are calculated once at runtime, they cannot be affected after the bundle has been processed. In React, you would create another component and do a conditional render of components.
Ah thanks! This all makes sense to some degree. These are regressions from babel though so it would be nice for them to be called out.
On my heroku dynos Iām getting this build issue:
RUNNING with --optimize_for_size --max_old_space_size=400 --gc_interval=100
State changed from starting to crashed
error on boot.js Error: Failed to load native binding
at Object.<anonymous> (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js:333:11)
at Module.<anonymous> (node:internal/modules/cjs/loader:1730:14)
at Module.Mp._compile (/tools/static-assets/server/runtime.js:78:21)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.<anonymous> (node:internal/modules/cjs/loader:1465:32)
at Module.Mp.load (/tools/static-assets/server/runtime.js:35:31)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Module.<anonymous> (node:internal/modules/cjs/loader:1487:12) {
[cause]: [
Error: Cannot find module './swc.linux-x64-gnu.node'
Require stack:
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/index.js
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/index.js
/app/.meteor/heroku_build/app/programs/server/boot.js
/app/.meteor/heroku_build/app/main.js
at Function._resolveFilename (node:internal/modules/cjs/loader:1401:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1057:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1062:22)
at Function._load (node:internal/modules/cjs/loader:1211:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Module.<anonymous> (node:internal/modules/cjs/loader:1487:12)
at Module.mod.require (/app/.meteor/heroku_build/app/programs/server/node_modules/@meteorjs/reify/lib/runtime/index.js:30:33)
at require (node:internal/modules/helpers:135:16)
at requireNative (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js:211:16) {
code: 'MODULE_NOT_FOUND',
requireStack: [Array]
},
Error: Cannot find module '@swc/core-linux-x64-gnu'
Require stack:
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/index.js
/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/index.js
/app/.meteor/heroku_build/app/programs/server/boot.js
/app/.meteor/heroku_build/app/main.js
at Function._resolveFilename (node:internal/modules/cjs/loader:1401:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1057:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1062:22)
at Function._load (node:internal/modules/cjs/loader:1211:37)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Module.<anonymous> (node:internal/modules/cjs/loader:1487:12)
at Module.mod.require (/app/.meteor/heroku_build/app/programs/server/node_modules/@meteorjs/reify/lib/runtime/index.js:30:33)
at require (node:internal/modules/helpers:135:16)
at requireNative (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js:216:16) {
code: 'MODULE_NOT_FOUND',
requireStack: [Array]
}
]
}
Error: Failed to load native binding
at Object.<anonymous> (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/babel-compiler/node_modules/@meteorjs/swc-core/.swc/node_modules/@swc/core/binding.js:333:11)
at Module.<anonymous> (node:internal/modules/cjs/loader:1730:14)
at Module.Mp._compile (/tools/static-assets/server/runtime.js:78:21)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.<anonymous> (node:internal/modules/cjs/loader:1465:32)
at Module.Mp.load (/tools/static-assets/server/runtime.js:35:31)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
at Module.<anonymous> (node:internal/modules/cjs/loader:1487:12)
Iām sure I need to copy over some binary or something, but I canāt quite figure out what/where ./swc.linux-x64-gnu.node should be copied from.
@ nachocodoner do you have any information/details that could help me out.
My build script can be found here meteor-buildpack-horse/bin/compile at master Ā· ToyboxZach/meteor-buildpack-horse Ā· GitHub
Edit:
I needed to install:
@swc/core-linux-x64-gnu
As an optional dependency, Iām not sure why that wasnāt automatically happening, but adding it to my top level resolved it
Meteor uses SWC binary on your native OS (swc.linux-x64-gnu.node) to do fast JavaScript transforms. SWC ships its platformāspecific binaries as optional packages (e.g @swc/core-linux-x64-gnu). I think the problem could be on Heroku skipping the binary of your OS. Without it, Meteor canāt require the native binding and crashes at boot. Good to see that adding it as a forced dependency makes it available for Heroku.
Most build plugins and packages used by build plugins lazily import large modules the first time they are used, so it doesnāt have to do unnecessary work loading the dependencies if not needed. This would also avoid this crash for apps that donāt need swc at runtime.
This probably should be done for swc, since in production it normally is only used if the app has a production Meteor shell or for some other reason wants to compile code in production (in the past there were some playground apps that did).
2 Likes
Can we have an option to only show errors instead of only verbose: true or verbose: false?
That would really help as the verbose: true slows down the start