Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-24591] Use package-lock.json instead of checking in node_modules

GitHub Issuen/a
TypeStory
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2017-07-20T22:56:11.000+0000
Affected Version/sn/a
Fix Version/sRelease 6.2.0
ComponentsAndroid, CLI, iOS, Tooling
Labelsn/a
ReporterChristopher Williams
AssigneeChristopher Williams
Created2017-04-18T15:55:45.000+0000
Updated2017-08-29T22:54:40.000+0000

Description

We've long checked in our node_modules folder when we update our npm dependencies. I believe we've done so to avoid npm dependency resolution issues? If so, we could move to using yarn and lock file to ensure the full tree of dependency versions matches on everyone's systems and builds - and avoid bloating the hell out of our repo size and history.

Comments

  1. Christopher Williams 2017-04-18

    One potential hangup is that we have a special 'titanium-sdk' module which actually only lives in the SDK repo, and has never been moved out to it's own package/repo. I've opened a PR to address that here: https://github.com/appcelerator/titanium_mobile/pull/8974
  2. Chris Barber 2017-04-18

    I'm fine with using Yarn, but now everybody MUST use Yarn. Just so everybody understands, Yarn should be installed via the recommended methods and NPM isn't one of them. Every developer will need to routinely run yarn upgrade after pulling the latest from git. We should document this in the readme and an email to all active committers would be appropriate. Also, I've seen the yarn.lock file be updated after doing yarn upgrade. The updated yarn.lock will be updated with any newly resolved versions, so we should probably instruct to use yarn upgrade \-\-frozen\-lockfile.
  3. Christopher Williams 2017-04-19

    [~cb1kenobi] Is there a particular reason we'd need to regularly run yarn upgrade after checkouts? Doesn't that make yarn attempt to upgrade all packages to the latest version within the semversion specs (and as a result also update yarn.lock)? Wouldn't we instead want devs to run yarn install to grab the matching dependencies from the lock file when it's been updated? I would assume we'd prefer to run yarn upgrade as a way to update our existing dependencies to the latest as a step near fork/release time just so we're not falling behind (and that we'd have to test/validate the upgrades). In other words, upgrade would be an intentional step in a PR that was tested/reviewed and would be meant to update the lock file.
  4. Chris Barber 2017-04-19

    I've only been running yarn upgrade as habit from running npm upgrade. If yarn install does the trick, then that's cool. Everyone will need to run yarn install after pulling the latest from whichever branch just in case the yarn.lock file changed. This will require an internet connection. These 2 reasons are why node_modules is in the titanium_mobile repo. I guarantee you someone will not remember to run yarn install and complain things aren't working all because of an out of date dependency.
  5. Chris Barber 2017-04-20

    Just to confirm, you are correct, we should run yarn install, not yarn upgrade.
  6. Christopher Williams 2017-06-02

    So, npm 5 just came out. Basically eliminates the need to use yarn and yarn.lock. Ugh, re-purposing this ticket to move to npm5 and package-lock.json file.
  7. Abir Mukherjee 2017-08-29

    PR was merged. Closing ticket as changes are seen in the latest SDK's

JSON Source