Generate paths for modular add#2111
Conversation
🦋 Changeset detectedLatest commit: 8cdfc02 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| export const packageRegex = | ||
| /^(@[a-z0-9-~][a-z0-9-._~]*)?\/?([a-z0-9-~][a-z0-9-._~]*)\/?(.*)/; | ||
|
|
||
| export function parsePackageName(name: string): { |
There was a problem hiding this comment.
This could do with a docstring with some examples of what each of the return values are.
| const installedPackageJsonPath = path.join(templateName, 'package.json'); | ||
|
|
||
| const { dependencyName: packageName, scope, module } = parsePackageName(name); | ||
| const { componentName, packagePath } = getNewPackageDetails({ |
There was a problem hiding this comment.
I suggest that it would be cleaner to call getNewPackageDetails(name) and return { packageName, packagePath, componentName }. This would move the call to parsePackageName into getNewPackageDetails and avoid declaring the scope and module variables in the scope of promptForName when they are only used once.
| }: AddOptions): Promise<void> { | ||
| const name = await promptForName(nameArg || unstableName); | ||
|
|
||
| // Validate package name |
There was a problem hiding this comment.
This entire validation section from 146 to 174 looks like it could go into a separate function.
| let newModularPackageJsonPath; | ||
|
|
||
| // try and find the modular template packge, if it's already been installed | ||
| // Find out if a package with the same name already exists |
There was a problem hiding this comment.
This entire validation section from 190 to 208 looks like it could also go into a separate function.
|
|
||
| // try and find the modular template packge, if it's already been installed | ||
| // Find out if a package with the same name already exists | ||
| if ((await getWorkspaceInfo())[packageName]) { |
There was a problem hiding this comment.
How long does this take in a large monorepo (e.g. 100-500 packages)?
There was a problem hiding this comment.
@sgb-io ran benchmarks on that, and we're < 2ms for 1k workspaces.
| } | ||
|
|
||
| // This function gets all the globs in "workspaces" field in the root package manifest | ||
| export async function getWorkspaceGlobs(): Promise<string[]> { |
There was a problem hiding this comment.
As this module exports 2 different workspace-related functions, perhaps it would better be called workspaces (i.e. this is where all utils for workspaces are placed).
There was a problem hiding this comment.
The second export isn't currently used in the project, so this could be private to the module
There was a problem hiding this comment.
Removed the export
| # `modular add <packageName>` | ||
|
|
||
| Adds a new package by creating a new workspace at `packages/<packagePath>` | ||
| Adds a new package by creating a new workspace at `packages/<packageName>`, |
There was a problem hiding this comment.
How about we have the 5 examples from the discussion thread right in the docs? I think it makes it really fast to understand how to use the option (even though your written docs are also good!)
| // Try and find the modular template package. If it's already been installed | ||
| // in the project then continue without needing to do an install. | ||
| // else we will fetch it from the yarn registry. | ||
| let newModularPackageJsonPath; |
There was a problem hiding this comment.
nit: not related to your change, but this could he instantiated with an explicit string | undefined type
TODO
Revised proposition with use-cases:
Validity checks (from @steveukx 's comment):
Assuming
--pathcontains a relative directory (would need to validate doesn't use..blocks to jump outside of repo root) that can be used in place of the default ./packages.Caveat of using a
--path, modular should check that the workspace would find the newly created package with the workspaces property in root package.jsonAdditional checks
Modular now checks for the existence of a package with the same name, using the workspace resolver. Before, if a workspace with the same name already existed, Modular would still add a new one, but Yarn would error at the end of the command, giving the impression that the command failed. Now the command fails straight away.
Modular now checks for the existence of the target directory and fail if the directory is not empty. Before, it just silently wrote in the existing directory without clearing it first (potentially overwriting some, but not necessarily all, files).