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
Setup turborepo, second try #52
Conversation
|
@@ -101,7 +101,8 @@ | |||
"types": "./dist/*.d.ts", | |||
"default": "./dist/*.js" | |||
}, | |||
"./addon-main.js": "./addon-main.cjs" | |||
"./addon-main.js": "./addon-main.cjs", | |||
"./package.json": "./package.json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a workaround for an unfortunate issue...
sync-pnpm
needs to find the hard linked package resolvable from the test-app, which is like a copy of our original addon in the monorepo, just without /dist
(which is the issue we need to fix here). But require.resolve('ember-headless-form')
does not work, because its main
field points to its ./dist/index.js
, which des not exist before we have actually synced. So resolve
throws.
Then I tried with this package that I found on npm, which basically tries to solve that issue: resolve-pkg. But running into sindresorhus/resolve-pkg#9.
So the workaround here is to make mypackage/package.json
resolvable. Not ideal, but works for now. Not sure if we can do this in any other way. We want to delegate the node resolution algorithm to node itself and not re-invent this, but there seems to be no way to say "give me the module path that you would try to require, without actually throwing when it is not available".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this one support exports? https://www.npmjs.com/package/resolve-package-path -- it's what auto-import uses
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to replicate the node module resolution, instead of delegating to node (like require.resolve
), so probably that would work! Thanks for the suggestion, will try this out!
Related: sindresorhus/resolve-pkg#9 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will try this out!
It works! 🎉
Total runtime is 22m: https://github.com/CrowdStrike/ember-headless-form/actions/runs/4194427919/usage can you push an empty commit? hopefully that'd be a full cache hit |
ea5282e
to
0188aca
Compare
For the record, caching seems to be fixed now. Total runtime < 9min - https://github.com/CrowdStrike/ember-headless-form/actions/runs/4196887915/usage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
Would be cool to see on ember-headless-table and ember-toucan-core, as well 🎉
Yeah, which brings us to the topic of what to do with |
I wonder if the turbo-repo folks would be interested in adopting it. I'll ask here: vercel/turbo#2306 |
I'll hold this back until we have #44 merged, so I can integrate the docs setup here too... |
8a8b9c5
to
733d8a8
Compare
Preview URLsEnv: preview |
56fef0e
to
1e61c65
Compare
87540ac
to
4c81454
Compare
import { getPackages } from '@manypkg/get-packages'; | ||
import { findRoot } from '@manypkg/find-root'; | ||
import { readJson, pathExists } from 'fs-extra/esm'; | ||
import { hardLinkDir } from '@pnpm/fs.hard-link-dir'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhhh - this is interesting!
Hard link (or copy if linking fails) all files from a directory to several target directories.
So essentially this sync file forces pnpm
to hard link the dependencies one way or another so that we don't have to continually pnpm i -f
anytime we make a change in the addon source and want to see it in the test-app/docs-app?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly. Also it does only this, it does not try to re-install/shuffle things around.
In an earlier attempt, I tried to just use pnpm i -f
in a turbo step, but when things run in parallel, this would lead to weird errors, as pnpm i -f
would temporarily remove things from node_modules
and add them back moments later, but in the meantime some parallel build would just fail as it would miss some dependencies in node_modules
.
So this does just adds back the missing hard links of our /dist
folder, and nothing else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing!!
So is the current development process now (for something like docs-app
):
- make a change in
ember-headless-form
pnpm build
- see the update in the
docs-app
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly, that should work (assuming you have pnpm start
or pnpm start:docs
running, to continuously rebuild the app).
It is a bit of a regression compared to other v2 addon setups (e.g. using yarn
), where this injected
thing does not exist (but instead other peer dependency related problems), so you could just run start
and it would watch the addon and the test-app. But not a regression compared to the previous state of this addon, because we had to run pnpm i -f
again and again, so this should make it better at least!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Definitely copying this for toucan-core
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just realized that the pnpm build
script does too much for this use case, as it builds the addons and the apps (test and docs). Will need another iteration!
Another attempt, using a custom sync step to work around vercel/turbo#2306
sync-pnpm
tool to sync the/dist
output_build
to call sync afterbuild
Best reviewed by commit (first one is #45 squashed into one)