Switch to npm

[ryanhamley]

Launch Checklist

• briefly describe the changes in this PR
• include before/after visuals or gifs if this PR includes visual changes
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/map-design-team @mapbox/static-apis if this PR includes style spec API or visual changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port
• apply changelog label ('bug', 'feature', 'docs', etc) or use the label 'skip changelog'
• add an entry inside this element for inclusion in the mapbox-gl-js changelog: <changelog></changelog>

[asheemmamoowala]

What minimum version of NPM is needed?

[arindam1993]

An appropriate version of npm gets installed whenever a version of node is installed, nobody generally has to think about this.

[ryanhamley]

Node 14, which we specify elsewhere, installs npm 6 by default (so does Node 10 and 12). It looks like Node 16 will install npm 7 by default when that becomes available. See nodejs/node#37689.

[arindam1993]

looks good to me, I'm so in for this.

[SnailBones]

Switching from yarn to npm means different commands for everyone building gl-js from source.

Can we get a review from the following teams? @mapbox/docs @mapbox/studio @mapbox/gl-native

[jseppi]

Should npm ci be used instead? This will guarantee consistency with the package-lock.json, and will error if there is a mismatch between the package.json and package-lock.json.

[jingsam]

This is a big step for the third contributors. Would you explain why we need switch from yarn to npm?

[ryanhamley]

We ran into an issue where installing a new dependency caused yarn to rewrite the entire yarn.lock file. This change also brings GL JS into line with most other Mapbox projects that use npm, so we won't run into issues with people using npm instead of yarn. Removing yarn also means one less thing for people to install to begin working with GL JS. The specific reasons that GL JS chose yarn years ago aren't big differentiators anymore so it feels like a good time to make this switch. For most use cases, it should be just changing yarn run <command> to npm run <command>. @jingsam is there a specific way that this would negatively impact your project that we might not be thinking of?

[mourner]

Let's not rush this through — we should take time to fully evaluate the impact, settle on the right NPM version (v7 has a different lock format), utilize npm ci where necessary, make sure all commands are working as expected, and measure performance for cold and hot installs.

[jingsam]

@ryanhamley Earlier mapbox open source projects are using yarn instead of npm. We follow this convention for years. we are satisfied for its performance and deterministic. We don't know whether npm v5 is a good choice. Even though npm v5 has released for years, majorities choose yarn. So I agree with @mourner . We would better to fully evaluate the impact first. I guess npm also can not guarantee that it will not rewrite the entire lock file when we installing or updating a package.

[ryanhamley]

Closing this for now since there was no clear consensus

[mourner]

Closing this for now since there was no clear consensus

@ryanhamley Let's rivisit this. I think there was consensus that we should evaluate switching to NPM, especially given that Yarn v1 is not very actively maintained, v2+ have low adoption, and that NPM has fixed most of its flaws in recent years, including fully deterministic builds with v7+ lockfile. It just needed more steps before a potential switch — e.g. consider potential upgrade to Node v16 LTS that comes with NPM v8 (or manually installing it with Node v14), measure cold and hot install time vs Yarn, etc.