Ark attest cannot find module error
Hello!
In a pnpm monorepo, with
@ark/attest installed in the workspace root and running pnpx run attest trace ., I get the following output:
What should I change to run it without issues?103 Replies
Well it looks like you're running from cjs so you'll need to add
"type": "module" to your package.json
It looks like from the stack trace attest's code is never executedEven with type module in the root package json it's giving the same error
Try adding more context without all the ...
I can't really see what's happening from that
Are there any changes I need to make to the code itself? Maybe I didn't understand the docs?
No haha
You just install the package and run that command you can tell it is not even running attest's code
Wait did you run
pnpm attest trace?
Or just attest trace
npm installing something doesn't put it on your path
Depending whether you're using npm/pnpm/yarn whatever just run it using thatpnpm attest trace . and pnpx attest trace . throw the same errorShow the whole output
"Starting: attest trace ."
Starting: attest trace ....
Error: Cannot find module '/home/p/Documents/Projects/web/attest'This seems kinda sus
That somehow it is not actually being resolved through node_modules
Should I hoist it?
No lol
I mean I don't know what's going on but I don't just have some random fix this is not a normal issue it seems like something with your env
Most attest users use pnpm like this
So it doesn't just not work haha
What isthe output for just
pnpm attest trace .The help section +
Just paste the whole thing
Including the command and all output
okay maybe I just broke it with the release yesterday then because I just changed how ts aliases are loaded
It worked for me locally but maybe something externally breaks
Should I try an older version?
You can try
0.17.0
As a testIt's the same
So an issue on my end
Oh yeah it works for me haha
I'll try messing around and see where the issue is
To be fair I did screw up this logging though with the new aliases it should say
Gathering type trace data for default or somethingNot really an issue :)
It's really weird that this can even go wrong
What happens when you run this command directly:
pnpm tsc --noEmit --extendedDiagnostics --incremental false --tsBuildInfoFile null --generateTrace .It's just the help section
Well you've lost me lol
That's just a vanilla TS command it runs fine for me
Don't know where else to go with that
Should I be running it from the workspace root?
I don't have a tsconfig file there per Turborepo's recommendation
It shouldn't matter as long as wherever you run it from
typescript is resolvable
You're right that is what happens if you have no tsconfig
You can try running it in a package dir with tsconfig
That's such a bad error from TS though I don't get itIt's doing something!
They don't even mention anything about needing a config, they just output a help message if you don't have one? @Andarist would you expect that?
Could u tldr for me?
I run this command and if there is no tsconfig in the dir it just outputs
--help
Works fine if there is a tsconfig
I guess that's what this is supposed to clarify:
Is the result the same when u try to run tsc with no cli args?
Yeah
I have never really tried to run tsc with no config so I've never seen this haha
Me neither ;p
But it seems like such an unhelpful error message
I would have known immediately what to do if it just said
"Running tsc with no args requires a tsconfig.json file"PRs are welcome - as i say 😛
Do they say why they recommend this? I can't imagine it would hurt to have one
Yeah, I am just worried it will languish and not get feedback or get rejected haha but this one seems like a pretty straightforward win
Hmmm, that is weird. It doesn't seem like it should matter if there is a root tsconfig as long as each package just extends it
Although this is the monorepo setup I recommend (w/
--customConditions):
https://colinhacks.com/essays/live-types-typescript-monorepo
IMO just being able to run/infer .ts in dev >>> needing watch mode all the time
And it's increasingly broadly viable now that --experimental-strip-types is built in to node
I will add some custom error handling for no tsconfig hereThank you for helping me with this
Is it normal do have 1882720 ids in the
types.json?It is a big file yeah
Is there something I should look into the most to understand where the bottlenecks are?
Creates a trace.json file in .attest/trace that can be viewed as a type performance heat map via a tool like https://ui.perfetto.dev/. Also summarizes any hot spots as identified by @typescript/analyze-trace.
Trace expects a single argument representing the root directory of the root package for which to gather type information.
AHHHH
Now I get it...
So with such a trace
This is the worst offender?
the types.json file can be used to associate IDs from the trace file with type aliases
17s? That's fucking awful
That has to be the worst I've seen for 1 type
😬
What is it lol
Let's see
I guess this?
Just what is in that position in the actual file?
In the TS file?
Yeah
It's the
domain.d.ts, is that right?Well there's a few questions haha
I'm ready
One would be you probably need to enable
skipLibCheck in your tsconfig to avoid typechecking your deps
But also that it is a very trivial type so there is no way that alone could be the source of something that takes 17 secondsDefinitely not
I have this in the tsconfig of the project I ran the attest command in
And every package extends a tsconfig with
"skipLibCheck": true,Hmm I mean type instantiations can still occur even with skipLibCheck on but that would usually be how a dep contributes a lot
I have this file
So that first huge source file that is checked is
domain.d.ts?Yes
I needed this because of the
not portable errorI don't know what the side effects of that are. I wouldn't guess they'd be that, but I would definitely try and avoid doing that if possible haha
And this package takes about 15-20 seconds to build the DTS files
Well they are real bad
Maybe try reading this comment about where that error comes from and see if you can find another solution:
https://x.com/ssalbdivad/status/1834752360729530575
David Blass (@ssalbdivad) on X
@mmkalmmkal @mattpocockuk Agree, would love to have some content on this that synthesizes @SeaRyanC's comment with other context on this issue.
Definitely a fairly universal pain point among library/monorepo maintainers in the ecosystem.
https://t.co/k0hvGB6s9I
Twitter
Whoops meant to link the github directly haha https://github.com/microsoft/TypeScript/pull/58176#issuecomment-2052698294
GitHub
Check nearest package.json dependencies for possible package names ...
Implements this comment.
I won't say this "fixes" #42873, but it does prevent it from occurring for people in workspaces with appropriately set-up explicit dependencies in...
The things is, I was trying to make the package have an exported config which uses Arktype types and exports the object. And then this object is imported in all other packages with the inferred types
Yeah it is true that transitive type resolutions like that can be tricky
But can you just make ArkType a peer dependency?
As in adding it to
dependencies in package.json?peerDependencies should require that the other package also installs it
Or rather that the other package installs it and you will use that versionWoooow!!!!
Then you can make it a
devDependency locallypackage.json | npm Docs
Specifics of npm's package.json handling
I never heard about this
You will, they cause a lot of problems TBH lol
Only saw it in libraries I guess
I mean it only makes sense as a library author to have them
By definition you have to have people depending on your package for it to be meaningful
Is that good?
Not really
Haha okay well you know 17 seconds on one type 8 seconds for the rest isn't bad 😛
I don't know what to look for 😬
I would probably try and start from an empty repo and see if you can bisect where these problems occur adding more of your code/configs
I never build types. I only do it here for the
not portable errorIt's tricky and takes a lot of practice TBH, that's how I make consulting money 😅
Nice!
What is the exact not portable error you get?
None right now... But when I import a function with such a signature
It's imported as such
That's with this in
package.json
With "types": "./dist/*.d.ts" there is no issue
So I guess there was an error with the dependency installation, as you've pointed outWhere is this from?
You almost certainly don't want to be resolving types to a .ts file, that is definitely something that can screw up your build
I was testing if the
portable error would happen with that in placeDid you read Ryan's comment?
I would read that and try and come up with a new solution for what specifically you need to export for the type to be resolved
The issue is gone after adding the package to
peerDependencies, thank youNow running
attest the biggest offender is this:
Yeah that file is definitely not the issue haha...
Tough to say without more investigation what is going on in your env, sadly I probably can't spent a lot more time speculating unless it is for a company that can pay me 😛
What are your rates so that I can come back when possible? ☺️
You've already showed me so much, thank you 🙏🙏🙏
Usually I have people contact me individually for that, but if your company is genuinely considering it DM me!