-
Notifications
You must be signed in to change notification settings - Fork 214
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
import @agoric/orchestration fails to find types.js #10086
Comments
Simpler repro,
Reasons not to change this:
|
How does that work? I'm struggling to confirm, fwiw. $ mkdir /tmp/fun1
$ cd /tmp/fun1
$ yarn add @agoric/orchestration@dev
$ node --input-type=module -e "import '@agoric/orchestration'"
node:internal/modules/esm/resolve:265
throw new ERR_MODULE_NOT_FOUND(
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find module ... |
I misremembered that it uses a It already has a So I don't have a good solution. There's a trade-off to be made. A reasonable stop-gap is that we remove |
I really don't think we should compromise on the public shape, which includes importing types from the entry point. I'm wondering if there's a possible solution for this type check issue: another level of indirection. Have index.js import from |
Good idea. I suppose a manual |
To clarify however, the output would be alongside the src, and not in a |
- add types.js indirection layer to fix ERR_MODULE_NOT_FOUND error. - maintains public API shape for intra-monorepo and npm installs. - closes #10086
- add types.js indirection layer to fix ERR_MODULE_NOT_FOUND error. - maintains public API shape for intra-monorepo and npm installs. - closes #10086
- add types.js indirection layer to fix ERR_MODULE_NOT_FOUND error. - maintains public API shape for intra-monorepo and npm installs. - refs #10086
- add types.js indirection layer to fix ERR_MODULE_NOT_FOUND error. - maintains public API shape for intra-monorepo and npm installs. - refs #10086
refs: #10086 ## Description - add types.js indirection layer to fix ERR_MODULE_NOT_FOUND error. - maintains public API shape for intra-monorepo and npm installs. ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations n/a ### Testing Considerations Includes a test in `packages/builders` that ensures `@agoric/orchestration` exports are reachable from a js file. ### Upgrade Considerations Library code for NPM Orch release
refs: #10086 ## Description Document the practice established in #10149 into a Best Practice. Adopt it in most packages. I only left these `types.d.ts` - swing-store because the file is only re-exports, nothing to typecheck - smart-wallet because there's no entrypoint for the package ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations per se ### Testing Considerations #10149 (comment) asked for more testing. This PR was originally intended to close the issue but the regression test is complicated enough and this PR has gotten big enough that I think it should land on its own. ### Upgrade Considerations n/a
refs: #10086 ## Description Brings all remaining packages into compliance with the best practice documented in #10158 Also has some other cleanup, separated by commit ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations none ### Testing Considerations none ### Upgrade Considerations none
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
packages/builders/scripts/orch-imp.js
node scripts/orch-imp.js
Expected behavior
No error.
Platform Environment
Node.js v18.20.1
git describe --tags --always
)66e4cc0 (actually a few commits from that version of master: b38b7f3 )
Additional context
@mhofman asked about this in #10057 (comment)
The text was updated successfully, but these errors were encountered: