You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer, using Nx, there are some edge cases (eg. serverless) that requires deep parsing. Instead of re-implementing a Tree walker that find usage of libraries from a file, I would prefer rely on internal Nx tools.
I found that using a combination of workspaceRootInner (find the root path), FSTree (build a Tree) and devkit would solve my use-case.
However, code inside of packages/nx isn't exposed to the public. It would be great to be able to rely on these utilities as it is extremely valuable.
Motivation
It would allow rely on Nx internal logics for pretty-much everything that is outside a generator.
Suggested Implementation
I am not part of the architecture team, so I might not be the best person to answer this.
Alternate Implementations
Not applicable, I think?
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏
Description
As a developer, using Nx, there are some edge cases (eg. serverless) that requires deep parsing. Instead of re-implementing a Tree
walker
that find usage of libraries from a file, I would prefer rely on internal Nx tools.I found that using a combination of
workspaceRootInner
(find the root path),FSTree
(build a Tree) anddevkit
would solve my use-case.However, code inside of
packages/nx
isn't exposed to the public. It would be great to be able to rely on these utilities as it is extremely valuable.Motivation
It would allow rely on Nx internal logics for pretty-much everything that is outside a
generator
.Suggested Implementation
I am not part of the architecture team, so I might not be the best person to answer this.
Alternate Implementations
Not applicable, I think?
The text was updated successfully, but these errors were encountered: