-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
feat(node): add a Node.js API #48
Comments
Thanks @Aghassi, I'm curious about this idea but I need to know a bit more about what you're trying to do. It could be that the output from This sounds interesting but I need a bit more context to get up to speed, thanks a lot David. |
Sure thing. My current situation is I'm writing a linter for The way arcanist is structured, it passes affected files into the linter and each file is linted with actionable information provided back to the user. Each lint message contains the line in the current file as well as the character that the error is located at. Here is an example of how I'm currently formatting the output for Arcanist // Create an array of errors splitting on a character syncpack provides
$errors = explode("✕", $stdout);
// For each error, create an error message
foreach ($errors as $error) {
// Report the error for each package
$message = new ArcanistLintMessage();
$message->setPath($path);
$message->setName('package.json Alignment Check');
$message->setCode($this->getLinterName());
$message->setDescription("Error, package mismatch found: \nx $error");
$message->setSeverity(ArcanistLintSeverity::SEVERITY_ERROR);
$messages[] = $message;
}
// Return the array of errors to be presented individually
return $messages; In terms of "why json", I just like JSON. No reason in particular. |
The library code and the CLI are separate in syncpack, so you could use it as a node module. It would be a small job to add a A little refactoring would be needed plus it's not a nice DX right now, but you can access the core functionality like so: const { list } = require('syncpack/dist/commands/list') You can see the code for the CLI and Library portions of the To make this more useful as a library some changes would be needed, eg. the Let me know if something like this would work for you. |
I'm currently just returning from a vacation, but I'd be happy to look at this. It sounds promising! |
The refactoring is now done, this feature shouldn't be too far off now. |
Closes #124 When using the `workspace` dependency type, packages installing that dependency no longer have to exactly match the `version` property of the package.json of origin. If the version or version range used by every dependent package matches, it is considered valid. Closes #130 JavaScript config files now have support for TypeScript IntelliSense. https://jamiemason.github.io/syncpack/config-file#typescript-intellisense Closes #114 Refs #109 Refs #125 Unsupported versions can now at least be managed via `pinVersion`, where previously anything which was not valid semver would be ignored. Refs #111 Refs #132 TypeScript IntelliSense support helps catch invalid config, but more work is needed to display useful error messages at runtime. Refs #48 Refs #3 Syncpack's internals are now better organised, so providing a Node.js API and general lint and fix CLI commands are now closer to being released. BREAKING CHANGES: Although they are still not auto-fixable, unsupported versions which were previously ignored are now acknowledged, which may introduce mismatches which previously would have been considered valid. This release was also a huge rewrite of Syncpack's internals and, while there is a large amount of tests, some scenarios may have been missed. If you run into any problems, please create an issue.
Closes #124 When using the `workspace` dependency type, packages installing that dependency no longer have to exactly match the `version` property of the package.json of origin. If the version or version range used by every dependent package matches, it is considered valid. Closes #130 Closes #131 JavaScript config files now have support for TypeScript IntelliSense. https://jamiemason.github.io/syncpack/config-file#typescript-intellisense Closes #114 Refs #109 Refs #125 Unsupported versions can now at least be managed via `pinVersion`, where previously anything which was not valid semver would be ignored. Refs #111 Refs #132 TypeScript IntelliSense support helps catch invalid config, but more work is needed to display useful error messages at runtime. Refs #48 Refs #3 Syncpack's internals are now better organised, so providing a Node.js API and general lint and fix CLI commands are now closer to being released. BREAKING CHANGES: - `fix-mismatches` will now exit with a status code of 1 if there are mismatches among unsupported versions which syncpack cannot auto-fix. - Although they are still not auto-fixable, unsupported versions which were previously ignored are now acknowledged, which may introduce mismatches which previously would have been considered valid. - This release was also a huge rewrite of Syncpack's internals and, while there is a large amount of tests, some scenarios may have been missed. - If you run into any problems, please create an issue.
### #124 When using the `workspace` dependency type, packages installing that dependency no longer have to exactly match the `version` property of the package.json of origin. Closes #124 If the version or version range used by every dependent package matches, it is considered valid. ### #130, #131 JavaScript config files now have support for TypeScript IntelliSense. Closes #130 Closes #131 https://jamiemason.github.io/syncpack/config-file#typescript-intellisense ### #109, #114, #125 Unsupported versions can now at least be managed via `pinVersion`, where previously anything which was not valid semver would be ignored. Closes #114 ### #111, #132 TypeScript IntelliSense support helps catch invalid config, but more work is needed to display useful error messages at runtime. ### #48, #3 Syncpack's internals are now better organised, so providing a Node.js API and general lint and fix CLI commands are now closer to being released. BREAKING CHANGE: - `fix-mismatches` will now exit with a status code of 1 if there are mismatches among unsupported versions which syncpack cannot auto-fix. - Although they are still not auto-fixable, unsupported versions which were previously ignored are now acknowledged, which may introduce mismatches which previously would have been considered valid. - This release was also a huge rewrite of Syncpack's internals and, while there is a large amount of tests, some scenarios may have been missed. - If you run into any problems, please create an issue.
Hi, I see that the PR for this was declined. Is there still a plan to expose a Node API for this? |
Hey @pastelsky, eventually that would be nice but for now I have closed it because:
So I would say Shubham that this is on a medium to long term pause, but not dead 👍🏻 EDIT: hey, you made bundlephobia.com 👏🏻 I use it all the time |
Hi @JamieMason, is an Node API still in the backlog? I have a rather unconventional use case where I want to be able to (temporarily) set dependency package versions to I'm aware this doesn't fully follow the goal of syncpack, which is why an exposed API where I utilise the So the workflow I'm looking to achieve is (monorepo project):
|
Description
This package is really great, but it would be nice for it to run sort of like a linter in that it should report to you the lines in the
package.json
that are impacted. This is mostly so that there may be a way to more easily identify which files need editing or updating for a given dependency.Suggested Solution
For a given scan:
paths
that represent the files that are mis alignedHelp Needed
At this point I just want to know if you are open to this feature, or if this is not the intent of the tool.
The text was updated successfully, but these errors were encountered: