Move into a single package.json #76412
Comments
|
Pinging @elastic/kibana-operations (Team:Operations) |
|
Would there be a single |
|
@kobelb, that is correct. |
|
@tylersmalley @mistic just looking to clarify the motivation behind a single package.json - is it because Bazel requires it, or for the benefits listed in the description? |
|
@peterschretlen I've talked with @tylersmalley about this offline. We believe both are present on that equation - we have started by looking at it because it was a blocker for our bazel exploration and then we discovered it might actually be a good idea anyway |
|
@peterschretlen it's actually both. Bazel currently does not support Yarn workspaces, however, it is something they are working to support but there is no timeline for that. While investigating this, we found that there are numerous benefits to migrating away from Yarn Workspaces as listed in the description. In addition, we have experienced constant issues with Yarn which we believe is only relevant to Workspaces. An example of this is some developers encounter an unexpected issue which is only resolved by clearing the I am working on generating a report to understand what dependencies have differing versions to understand the scope and what is needed. |
|
Here is a report of our dependencies with different versions across packages. For the most part, seems like we have a lot of opportunities to reduce our overhead. The script for my future reference
const { readFileSync } = require('fs');
const globby = require('globby');
const packagePaths = globby.sync(['**/package.json'], {
gitignore: true,
});
const dependencies = {};
function addPackage(name, version, packagePath) {
if (version.match(/link:/)) return;
if (!dependencies[name]) {
dependencies[name] = [];
}
dependencies[name].push({
path: packagePath,
version,
});
}
function checkPackages(packages, packagePath) {
if (!packages) return;
for (const [name, version] of Object.entries(packages)) {
addPackage(name, version, packagePath);
}
}
packagePaths.forEach((packagePath) => {
try {
const pkg = JSON.parse(readFileSync(packagePath));
checkPackages(pkg.dependencies, packagePath);
checkPackages(pkg.devDependencies, packagePath);
} catch (e) {
console.log(`failed to parse ${packagePath}`, e.message);
}
});
Object.keys(dependencies).forEach((name) => {
const dependency = dependencies[name];
const unique = [...new Set(dependency.map((d) => d.version))];
if (unique.length > 1) {
console.log(`${name} (${unique.join(',')})`);
dependency.forEach((d) => console.log(` - ${d.path}@${d.version}`));
}
}); |
|
To get a picture of how this would impact solution teams, we can break this out by plugins that are actually using workspaces. These are the only plugins using custom package versions:
So today, none of our plugins are using custom versions of package in their actual product. We only have APM using a few custom versions in their custom tooling for cypress. Only 3 of these seem potentially problematic (indicated by the However, I don't suspect these will be too bad to fix. The We used to have more teams using custom versions of packages than we do now. I think this is a good sign that this workspaces feature is no longer needed frequently and we can probably live without it for a while. |
|
@joshdover @tylersmalley just to let you know that we merged #78825 so at the moment we no longer have multiple dependencies declared for the same dependency across the repository |
Will devs be able to use aliases to add, say, I understand not wanting N versions with minimal differences but there have been a few occasions where this has been a critical feature. |
|
@jfsiii I would say using alias would be available to be used for such occasions 😃 I felt how useful it can be in a couple of situations for example during the work to migrate lodash 3 to lodash 4 across the entire repo, so we plan to keep that ability. |
The proposal is to use a single top level package.json (in the kibana folder) to manage all the dependencies we need in the workspace. Sub-directories package.json will still be found from now in order to keep defining and informing boundaries around plugins and packages from the core and also to allow to run specific npm scripts. In the future those sub directories package.json could maybe be removed and replaced with BUILD.bazel files which can both be used to inform boundaries and also to define nodejs scripts to be run with bazel instead of npm.
Benefits
Cons
Steps
@kbn/pmpackage.jsonlink:instead of version in the root package.jsonlink_project_executables.tson@kbn/pmto link the root./node_modules/.binfor every@kbn/pmproject so we can run npm scripts on themThe text was updated successfully, but these errors were encountered: