Skip to content

feat: show warning when dependenciesMeta.{built,unplugged} is declared in non-top-level workspace #3923

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

paul-soporan
Copy link
Member

What's the problem this PR addresses?

Just like the resolutions field, dependenciesMeta.{built,unplugged} can only be declared inside the top-level workspace manifest, but we don't currently show a warning if it is declared inside a workspace manifest.

How did you fix it?

Made it show a warning in that case.

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

@@ -427,6 +433,8 @@ export class Manifest {
errors.push(new Error(`Invalid built meta field for '${pattern}'`));
continue;
}
if (typeof built !== `undefined`)
topLevelWorkspaceFields.add(`dependenciesMeta ➤ ${pattern} ➤ built`);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's really unfortunate that we can't use colors in here, but it feels wrong to pass configuration as part of an option bag parameter to Manifest.prototype.load.

@arcanis
Copy link
Member

arcanis commented Jan 3, 2022

While I see the point, I'm not super fan of making Manifest.load aware of whether the "parsing mode" is top level or not. It feels like the CorePlugin should be the only one to decide (just like it's currently implemented), rather than adding another "return property" to the manifest class 🤔

@paul-soporan
Copy link
Member Author

paul-soporan commented Jan 4, 2022

While I see the point, I'm not super fan of making Manifest.load aware of whether the "parsing mode" is top level or not.

It is not aware itself of the parsing mode, it just tells whatever is using it to enforce that some fields must only be declared in the top-level manifest. IMO, being aware of the parsing mode would mean passing an isTopLevel flag to manifest.load and throwing errors inside of it. This PR is trying to achieve the exact opposite.

I feel like this is the cleanest approach that still decouples the manifest parsing from the workspace that contains it.

@merceyz
Copy link
Member

merceyz commented Jan 6, 2022

I agree with @arcanis, this seems to belong in validateWorkspace and not in the Manifest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants