New Build for Core+persistence
nmn opened this issue · comments
In the current build schemes, If I want persistence, I have to also take views etc. There should a build just for core+persistence.
Hey ya,
I think I'd like a build system similar to jQuery UI so you can tick the modules you want and download like that. I'll be adding more build files for different combinations in 1.2.9, I've added a note to the roadmap too. Thanks! :)
Hi, I've been making some changes, and I'll be sending a pull request for some changes.
I primarily work with browserify and npm. So my focus will obviously be on that aspect.
I think it makes sense to provide a links to the files in the build folder for node and browserify and use a UMD wrapper for standalone and require.js builds. This would however, require, a pretty big tooling change.
Another thing I wanna know is what purpose does the server folder serve? It looks like example code, but I wanted to confirm.
Hi, I've been making some changes, and I'll be sending a pull request for some changes.
I primarily work with browserify and npm. So my focus will obviously be on that aspect.
Cool.
I think it makes sense to provide a links to the files in the build folder for node and browserify and use a UMD wrapper for standalone and require.js builds. This would however, require, a pretty big tooling change.
I thought that the builds were already generating a UMD wrapper with the browserify -s ForerunnerDB option?
Another thing I wanna know is what purpose does the server folder serve? It looks like example code, but I wanted to confirm.
That is actually a somewhat working server-side system for Forerunner. It is alpha code and more of an experiment at this stage than anything else. As per the roadmap it will be moved into it's own repo going forward from 1.2.7 (the latest dev branch build). Once 1.2.7 is ready to merge both the iOS and server folders will become their own repos.
I thought that the builds were already generating a UMD wrapper with the browserify -s ForerunnerDB option?
Yes, my point being that the UMD is only needed for standalone and bower builds. We should just provide an entry file for node and browserify.
I agree that the iOS code belongs in a separate repo.
For the server-side code:
If the server-side version FDB will have an almost identical or very similar API as the client-side API, then I think it makes sense to keep it in the same repo and publish it as a single package on NPM so it can be an isomorphic library like superagent
Yes, my point being that the UMD is only needed for standalone and bower builds. We should just provide an entry file for node and browserify.
Ahh I see, yes that is correct.
If the server-side version FDB will have an almost identical or very similar API as the client-side API, then I think it makes sense to keep it in the same repo and publish it as a single package on NPM so it can be an isomorphic library like superagent
It does use the exact same API with a few extras. The only issue with keeping it in-repo is that the dependencies you moved to dev-dependencies are actually all server-related. It makes it difficult to provide separate dependencies for them. Perhaps we can make Forerunner a dependency of the server its own repo so its not polluting this one with them?
In that case we can just move the devdependencies back into the dependencies bucket, once the server-side code is slightly more stable.
That said, forever is still a devDependency and it can remain where it is.
Making FDB a dependency of FDB-server will also work in theory. But I think there might be some problems for people who are trying to write isomorphic apps and require the app on the both the client and the server with the same code.
The core doesn't reference the dependencies anywhere, so even though it may be an extra few packages to download once, they won't get bundled in a browserify bundle so I don't think it'll be a problem.
OK cool beans. :)
I'm not sure how to depend on local forage though? should it be a dependency, or should there be an API for the user to give access to it?