Closed Hotell closed 3 months ago
@Hotell oopsie, good catch 👍
packageName
is defined there and is used also for upload-report
:
As it's used in multiple places IMO it should be hosted in a config. As monosize
is still in 0.x
, IMO it's fine to break it for good 🐱
I propose:
export type MonoSizeConfig = {
repository: string;
storage: StorageAdapter;
bundler: BundlerAdapter;
+ packageName?: async (packageRoot: string) => Promise<string>;
};
packageName
is present, we will let users to define their own thingpackageName
is absent, we will use name
from package.json
i.e. @fluentui/react-image
instead of react-image
like nowWDYT?
For sake of simplicity this is good enough IMO from configuration POV, not sure about the defaults (inferring name from package.json):
package.json
, monosize would provide invalid results/throw error by default. project.json
(nx ecosystem) for non publishable packages (another case of invalid output )but I'm ok to go with this and provide appropriate error messages to user.
WDYT?
For sake of simplicity this is good enough IMO from configuration POV, not sure about the defaults (inferring name from package.json):
- If user library(package) doesn't contain
package.json
, monosize would provide invalid results/throw error by default.- now some libraries might use only
project.json
(nx ecosystem) for non publishable packages (another case of invalid output )
That's a good call out. Then let's keep directory name as a default? So there won't be breaks at all.
If we want to handle these scenarios better, we also need to make findPackageRoot()
configurable as currently it accounts only for package.json
:
so to recap the solution we wanna go forward with:
packageName?: async (packageRoot: string) => Promise<string>;
Additional thoughts:
so if we update package root retrieval to account for project.json
or package.json
why not leverage it to get the name property from there already ==> this would imply default name resolution like (package.json#name ?? project.json#name ?? directory-name)
Additional thoughts:
so if we update package root retrieval to account for
project.json
orpackage.json
why not leverage it to get the name property from there already ==> this would imply default name resolution like (package.json#name ?? project.json#name ?? directory-name)
What about this plan then? ⬇️
packagePath?: async (filepath: string) => Promise<string>
(filepath) => findUp(['package.json', 'project.json'], { cwd: path.dirname(filepath) })
packageName?: async (packageRoot: string) => Promise<string>;
package.json#name ?? project.json#name
(it can't fallback to dir name as may not find package.json
or project.json
)sounds good 🤝 !
I'll implement this next week. ty !
ATM packageName for local report is being inferred from package folder basename https://github.com/microsoft/monosize/blob/main/packages/monosize/src/utils/collectLocalReport.mts#L23
While this might work for simple use-cases once it should be configurable by the user.
Example
when directory structure is (see within PR)
Current:
Expected:
Proposed Implementations:
package.json#name
and fallback to folder basename if not presentThis would be a BREAKING CHANGE