Lock packages best practices

Hi,

My question is related to the bug reported in the issue https://github.com/angular/angular-cli/issues/9276 and more an educational topic for myself and I hope for the community.

I saw from the @filipesilva comment that is advised to release also the lockfile, which is fine for me, this will make sure that the software that I release will work at the same way on my machine and on the next person that will install it (good).

My question is more on how you as Angular CLI team make sure that the Angular CLI will work at the same way on my machine and on your machine? Let’s suppose that you test your software and all is fine…now in between your release and me using it, one of your dependencies release an update that changes the behaviour of your software, not necessarily breaks it, what stops this thing from happening?

If what I’m describing is correct, I would also be interested in understanding why during the release phase you are not locking the dependencies in the package.json file?

Thank you

Versions

<!--
Output from: `ng --version`.
If nothing, output from: `node --version` and `npm --version`.
  Windows (7/8/10). Linux (incl. distribution). macOS (El Capitan? Sierra?)
-->

Your global Angular CLI version (1.6.5) is greater than your local
version (1.5.0). The local Angular CLI version is used.

To disable this warning use "ng set --global warnings.versionMismatch=false".

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/
    
Angular CLI: 1.5.0
Node: 8.5.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/.DS_Store: error
@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.0
@angular/flex-layout: 2.0.0-beta.10
@angular/material-moment-adapter: 5.1.0
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.41
@angular-devkit/core: 0.0.28
@angular-devkit/schematics: 0.0.51
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.16
typescript: 2.4.2
webpack: 3.8.1

Repro steps

• Install angular-cli 1.5
• ng new test-project
• ng serve

Observed behavior

<!-- Normally this includes a stack trace and some more information. -->

> module.js:540
>     throw err;
>     ^
> 
> Error: Cannot find module '@angular-devkit/core'
>     at Function.Module._resolveFilename (module.js:538:15)
>     at Function.Module._load (module.js:468:25)
>     at Module.require (module.js:587:17)
>     at require (internal/module.js:11:18)
>     at Object.<anonymous> (C:\Users\xxx\AppData\Roaming\npm\node_modules\@angular\cli\node_modules\@angular-devkit\schematics\src\tree\virtual.js:10:16)
>     at Module._compile (module.js:643:30)
>     at Object.Module._extensions..js (module.js:654:10)
>     at Module.load (module.js:556:32)
>     at tryModuleLoad (module.js:499:12)
>     at Function.Module._load (module.js:491:3)

Desired behavior

Project starts

Mention any other details that might be useful (optional)

[DenysVuika]

@filipesilva Just to give some context. We release a project that has been tested and confirmed to work properly. A couple of days later, at the conference, it suddenly stops working for developers and consumers, for everyone.

So we have spent a lot of time trying to find out why everything broke after simple npm install and why all CLI commands not working without adding “devkit/core” and "@angular-devkit/schematics": "0.0.34" to the package. And face the need re-publishing everything we released just because someone in your team broke library other CLI library depends on in a non-strict/pinned way.

The question is, how we can now be sure you are not going to break everything once per day with “sorry, guys, you need to upgrade”? One of the suggestions, as @magemello mentioned - that you pin all the dependencies the CLI tools have, and those our projects get indirectly.

[magemello]

@filipesilva & @hansl any chance you are going to include the package-lock in the generated app to make sure we are running the same software you tested?