-
Notifications
You must be signed in to change notification settings - Fork 39
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
Add apache-annotator meta-package #94
Conversation
I think this can be automated with lerna or yarn. |
{ | ||
"name": "apache-annotator", | ||
"version": "0.1.0", | ||
"description": "Web Annotation selector for engine.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe pull the description from the root package.json. The root one might not even need a description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yes; I just copied the package.json
from the selector package. We should probably give that one a less cryptic description some day. :)
I see that while copying I also left its dependencies, and pointer to its type declaration file; I removed both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. I left two small comments, but this is perfect.
8caeb3f
to
98ea021
Compare
I believe we do want the types and the dependencies. Even just importing things leads to the build having babel import helpers from the runtime package. We may not need core-js@3 at all, since I think it's bundled in the babel runtime package. I'll remove that after I merge. |
98ea021
to
8934df0
Compare
A step towards addressing issue #90. This first approach exports through both ways I mentioned there, so a user can do either of the following:
I’d be happy to drop one of the two if there is no reason to keep both.
Before a release, we’d have to manually update the packages’ version numbers in
package.json
. Also when adding a package, we’d have to add it manually in several places. Neither is too much hassle I suppose, but if there’s a simple way to automate such tasks that could be nice.