Best practice for developing library + app at the same time

[John D. Ament]

Hi,

So I was wondering, what approaches can/should be taken if you're developing both a library and an app at the same time.  Our app is a UI based app, running in the browser, but there's an underlying library that we leverage that includes some of our basic UI components.  This library changes infrequently but it does change.

We're very much a bunch of guys who have done server side java development for a while, and now have a need to do some UI development.  Someone wrapped this library in a maven build, which somewhat works.  Ideally what we want is that when a change is made to the library, CI runs and deploys the artifact somewhere.  This part works fine.  However, we also have cases where you are doing local development and don't want to publish your changes until you're sure they work in the app.  In either case, we're going to pushing out something with a version #, and that version # need not change with every commit.  Will npm poll the repository still for changes?

Currently all of our builds are based on npm link.  Looking at how it works, I'm thinking its not a good idea since it creates a global link.  We've had cases where code leaked into the wrong branch because of the global link in our CI.

Any tips, pointers, I'm sure I sound a bit confused. ;-)

John

[Ryan Graham]

Releases packages are not expected to change. This is sort of a core assumption within npm and, as I understand it, quite central in its caching strategy.

Have you considered simply incrementing the version number with these automatic releases? I've found that to work fairly well for us at StrongLoop, though it does require a certain degree of work to get all the pieces in place for CI and dev to work this way.

Our workflow is heavily based on pull requests, which are tested on CI both directly with npm test and indirectly by testing dependant modules against the proposed changes. Once it all passes and is merged, CI cuts an untagged patch release and publishes it to our staging registry. The version number used for each staging release is basically MAX(published + 0.0.1, package.json). If a PR introduces a breaking change we increment the major as part of the PR. This way our other modules have to be modified to opt-in to the updated dependency. In other words we use semver within our dev process, not just at release time.

That's about all I can handle typing on a phone at the moment. I can elaborate further if needed, but I think that answers the question.

~Ryan

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/2577fc26-2fc0-479a-99e0-4ce4b88fdfd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

~Ryan

[Angel Java Lopez]

I'm not sure about how you use npm link, and you use of "global", and your CI

But for local development, usually I have

/git/mylibrary

/git/myapp

Then

cd /git/myapp

npm link ../mylibrary

and a new symbolic link under /git/myapp/node_modules is created, without having to publish mylibrary into global npm

Hope it helps

Angel "Java" Lopez

@ajlopez

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAGjmZGyn%2B7u4n0MEVVnJqrD3gZUFqkz_PYdTjeBL7ZXRjhPqhw%40mail.gmail.com.