Open dy opened 4 years ago
Or, removing "type": "module"
from package.json
would suffice - it would make haunted possible to be consumed both by commonjs
and esm
.
CommonJS wrapper sounds like a good idea to me! I probably won't have the bandwidth to work on this until this weekend at earliest however. If someone wants to submit a PR that would speed things along.
SSR/jsdom/browser-env tests in node@13 isn't possible due to that reason.
Importing haunted directly via import
is also blocked.
internal/modules/esm/default_resolve.js:94
let url = moduleWrapResolve(specifier, parentURL);
^
Error: Cannot find module C:\projects\any-hooks\node_modules\haunted\lib\lit-haunted imported fr
om C:\projects\any-hooks\node_modules\haunted\lib\haunted.js
at Loader.resolve [as _resolve] (internal/modules/esm/default_resolve.js:94:13)
at Loader.resolve (internal/modules/esm/loader.js:74:33)
at Loader.getModuleJob (internal/modules/esm/loader.js:148:40)
at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:41:40)
at link (internal/modules/esm/module_job.js:40:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
With native node ESM modules support https://nodejs.org/api/esm.html, node recognizes haunted as
module
duringimport
. That causes problem thathaunted
is impossible to be imported viarequire('haunted')
. That's possibly fine with the package, but that creates side-effect: now it is impossible to detect ifhaunted
is installed in deps, because installed package detection is only possible via optional requiretry{ require(pkg) } catch (e) {}
, until the top-level await is implemented.As a consequence, packages like any-hooks, enhook, unihooks etc are unable to detect
haunted
.I'd suggest providing simple commonjs entry/wrapper, as suggested in https://nodejs.org/api/esm.html#esm_approach_2_isolate_state. The example is htm.
@matthewp do you have considerations on that?