-
Notifications
You must be signed in to change notification settings - Fork 14
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
Peer Dependencies on @screeps projects #24
Comments
Here's my reasoning. 24e3a47
|
Ok that makes sense, but I still feel it is masking the problem. And that isn't actually true: @screeps/common is indeed directly referenced by this package so it should be a true dependency, and it is in fact provided by this this package (transitively through @screeps/screeps). I think the real issue is "what is the purpose of @screeps/screeps?". It is supposed to be a standalone wrapper around all of the screeps components, including the launcher and UI, for launching a private server. But that isn't quite what we are doing, we are picking up the components from @screeps/screeps, and rebuilding them ourselves into a custom runner (screepsServer.js) which can be controlled on a per tick granularity. This kind of thing is actually exactly what the separate of the screeps components is for. You can pick and choose your components and glue them together yourself. Thesefor, I propose the following:
We will need to keep these in sync with the latest versions (just like now #23 ) -- Consumers of this project will not need to provide any other screeps components, as they will all be included in here. -- Totally separate topic, feel free to move. But since we have @screeps and all it's components, would it be possible to launch a UI to view the state of the mockup server? that would really help with visual debugging of integration tests. |
Does anyone know why this project has peer dependencies on the various @screeps component?
https://nodejs.org/es/blog/npm/peer-dependencies/
As far as I know, the point of peer dependencies is for "plugins" which all use a core library but don't want to version lock the consumer into a specific version of that dependency. This is particularly relevant if the consumer would also want to directly use that core library.
We already have a direct dependency on screeps itself, which has a direct dependency on all of the same components. I don't see any benefit to including these peer dependencies.
The text was updated successfully, but these errors were encountered: