splits core and app into separate packages, adds complete configuration for dev and production #67
Conversation
adds ejected create react app configuration to app moves tests to subdirectories of components linting changes
christopher-johnson
force-pushed
the
cra-eject
branch
from
96a943d to
582d3bc
Compare
handles prop updates in Window replaces binds with arrow functions excludes console in eslint adds build to .gitignore adds lerna.json
There was a problem hiding this comment.
Thanks for submitting this @christopher-johnson.
I think before we can move forward with this a few things to consider:
- One of the reasons we left it as a single package, is it was unclear what that separation layer might be. For instance, do we know that adopters will want to use the core separately? Especially if it is coupled tightly to the UI? And if so, will it make it hard to maintain this library (and version compatibility mismatch) if they are separately versioned? These are just some of the things I've been wondering about before going down the path of separating packages. I understand the technical approach, just in my experience with maintaining open source software, does the added overhead give us a maintenance improvement or does it become a hindrance.
- If we do go down this path, I'm not clear how to get this running together with the tests.
npm startisn't doing it for me. Is that the way to do it? Is there supposed to be ansrc/index.jsin themirador-3-coredirectory? - The original source files should be moved in version control so they maintain their history.
|
thanks for the review @mejackreed . one simple way to look at the separation between core and app is API vs. implementation. Whatever is in core is implemented in app. Semantic versioning of core is critical as there may be many different apps built from it. Coming from the Java world, I can say with certainty that separating implementation from API is very important for maintainability. To get it running, you need to I agree that history should be maintained. I take care of this in a new commit. |
|
moving history required creating a new branch, so I will close this PR and resubmit with new branch |
closes #66
This structure provides a basis for extensible "package oriented" component design and testing with a development server and environment and also a production deployment of mirador app. There are many, many options with webpack, so this should not be considered complete, but does provide reasonable defaults for further enhancement.
The separation of versioned libraries and feature/plugin components from the main app allows maintainability as the code-base grows. Currently, there is one library, "mirador3-core" which provides redux actions and reducers.
As a library then, mirador3-core is just a npm package and can be published by itself. Currently, since it is not published, it is referenced in the package.json with "file://"
The option in
minimal_redux_pocto provide a distribution binary of mirador3-app for an non-optimized production app build can also be provided, though this has not been included in this PR. Note that production deployment with webpack primarily involves chunking, and this cannot be achieved with a distribution binary. Chunking optimizations are particularly advantageous for mobile platforms.The tests do run and most pass, but there are now a couple of failures. I suspect that this can be addressed in a subsequent PR.
Running the app can be done with "npm start" from the packages/mirador3-app directory. lerna could be added to make building and testing multiple packages easier.