-
Notifications
You must be signed in to change notification settings - Fork 3
Conversation
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.
LGTM!
return {} | ||
} | ||
|
||
const buildInfo = async function (context) { |
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.
[sand] Am I right in thinking that this function exists because in the future buildInfo
may return more data, which it will collect from functions other than getWorkspaceInfo
. If so, would it make sense for getWorkspaceInfo
to return just the data (e.g. return { isRoot, packages }
) and let buildInfo
be in charge of defining the keys it exposes?
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.
Good point 👍 addressed via 27af306
4a8a7be
to
62ea544
Compare
9c3cf68
to
baa1e00
Compare
baa1e00
to
c46f488
Compare
This PR adds support to detect
js-workspaces
:We're currently detecting 2 scenarios. The first one is if your project is actually building from a root workspaces project (not making use of the base property config). The second scenario is if you're pointing to a project that is a workspace itself, with the root
package.json
present in the root of the repo.I've opted for using the
map-workspaces
project fromnpm
, as it provides the paths for the workspaces out of the box and handles the glob expansion. Even though we're not planning to use thepaths
right away I figured it's a useful bit of info that we're probably going to rely on a near future. Also added a flag to distinguish if a project is pointing to the workspaces root, or is actually a workspace itself.