Teradata Engineering

We are closer to Node Developers now whether we like it or not...

• webkit
• import
• package.json

Node Development best practices...

• small concerns / small modules
• flexibility
• lean on versioning

What is a locking file...

• single project install repeatability (from date of inception)
• targeted upgrading
• unless locked down will take non breaking changes (a good thing! bug fixes from the community etc.)

What does a locking file not do...

• keep module versions across projects consistent
• solve all our problems :)

OSATs is our development teams largest blocker

• not clear on subdeps
• can't make things flat (especially dev dependenices and sub-deps)
• going against the NODE development grain with not taking minor/patch non breaking changes
• we suffer flexibility (can't be smart about when and where we upgrade anymore)
• how does this affect sustaining bugs?

OSAT solution...

• locked down frontend dependencies or browser dependencies
• use a shared module for dependencies to get every SPA and module on the same page
• dev dependencies will be harder to lock down as they depend on sub-deps etc. and minor updates to work
• can't flatten dev dependencies (nightmare!)

interesting stats

• workflow-ui dependency count ~ 3,515 unique
• dependencies(browser deps) ~ 202 unique
• devDependencies ~ 2475 unique

don't forget the first count is unique but could have multiple versions of the same dependency!

thanks!