Milligram: Remove the engines property from package.json

Created on 10 Jun 2020  ·  10Comments  ·  Source: milligram/milligram

Does the node version really matter?

awaiting reply

Most helpful comment

@davidroeca @westtrade please, can you tell me what happens when you install Milligram?

I know that we have 2 great examples, and as I understand, the first example uses a version before LTS and the second example uses a version after LTS, and both examples are affected.

First, I would like to know if the same behavior happens when using Yarn and Npm.

Besides, the same behavior happens when you use or install Milligram v1.4.0 and v1.3.0 (last versions)?

In my case, it simply does not install, and NPM throws an error that I wrote in the title. Your framework is wonderful - but it’s strange that the style framework requires a server interpreter version. Wouldn't browser styles work without a server interpreter?

All 10 comments

@westtrade Milligram was upgraded to the LTS version of Node.js, as it is a highly recommended practice to keep all dependencies current.

Please, can you explain with details why Milligram needs the Node.js v11?

Just stumbled upon this issue myself. Currently on node 14, the bleeding edge, and using svelte, which is also on the bleeding edge. As a user, it's a bit odd to have a css-only framework tell me which engine of node I'm supposed to be on. I assume this engine flag is more useful for the developers of milligram itself?

An easy work-around for this issue in yarn is yarn add --ignore-engines milligram, and tell anyone who clones your repo to yarn install --frozen-lockfile --ignore-engines rather than just yarn install --frozen-lockfile. However, this is not ideal, given that all I'm importing is css.

@davidroeca Yes. The Node.js version is defined because it is required for the development environment of the Milligram. Besides, it is a highly recommended practice to keep all dependencies current. In this case, Milligram uses the LTS version (v12) of the Node.js.

So, let me better understand what's going on and maybe we can help improve it.

@cjpatoilo I agree that it's best to keep packages current. I'm actually more current than v12. My issue is slightly different than @westtrade's issue because mine can be solved by switching the engine caret requirement to >= to allow for future node versions as well:

  "engines": {
-    "node": "^12.17.0",
+    "node": ">=12.17.0",
    "npm": "^6.14.5"
  },

A similar discussion has taken place in the bootstrap repo. They opted to remove the engines field entirely, because these specific engines are only necessary to create the dist/ folder that users are using. This happens in the build step, so I actually don't need anything JS-related to download these files.

From a development standpoint in this repo, does a note in the README specifying the supported node version + a CI environment with a pinned node version suffice in this regard?

@westtrade @davidroeca for now, I will remove engine from package.json

@davidroeca @westtrade please, can you tell me what happens when you install Milligram?

I know that we have 2 great examples, and as I understand, the first example uses a version before LTS and the second example uses a version after LTS, and both examples are affected.

First, I would like to know if the same behavior happens when using Yarn and Npm.

Besides, the same behavior happens when you use or install Milligram v1.4.0 and v1.3.0 (last versions)?

With npm, I get the following warnings:

❯ node --version
v14.4.0
❯ npm --version
6.14.5
❯ npm install --save milligram
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN notsup Unsupported engine for [email protected]: wanted: {"node":"^12.17.0","npm":"^6.14.5"} (current: {"node":"14.4.0","npm":"6.14.5"})
npm WARN notsup Not compatible with your version of node/npm: [email protected]
+ [email protected]
added 2 packages from 1 contributor and audited 2 packages in 1.581s
found 0 vulnerabilities

With yarn, it's an error:

❯ node --version
v14.4.0
❯ yarn --version
1.22.4
❯ yarn add milligram
yarn add v1.22.4
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version "^12.17.0". Got "14.4.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Going down to 12.8.0

❯ node --version
v12.18.0
❯ npm --version
6.14.5
❯ npm install --save milligram
npm notice created a lockfile as package-lock.json. You should commit this file.
+ [email protected]
added 2 packages from 1 contributor and audited 2 packages in 0.876s
found 0 vulnerabilities

With yarn:

❯ yarn --version
1.22.4
❯ yarn add milligram
yarn add v1.22.4
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 2 new dependencies.
info Direct dependencies
└─ [email protected]
info All dependencies
├─ [email protected]
└─ [email protected]
Done in 0.34s.

With milligram@~1.3.0, I can use the latest version of nodejs with no problems:

❯ node --version
v14.4.0
❯ yarn add milligram@~1.3.0
yarn add v1.22.4
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 2 new dependencies.
info Direct dependencies
└─ [email protected]
info All dependencies
├─ [email protected]
└─ [email protected]
Done in 1.47s.

@davidroeca @westtrade please, can you tell me what happens when you install Milligram?

I know that we have 2 great examples, and as I understand, the first example uses a version before LTS and the second example uses a version after LTS, and both examples are affected.

First, I would like to know if the same behavior happens when using Yarn and Npm.

Besides, the same behavior happens when you use or install Milligram v1.4.0 and v1.3.0 (last versions)?

In my case, it simply does not install, and NPM throws an error that I wrote in the title. Your framework is wonderful - but it’s strange that the style framework requires a server interpreter version. Wouldn't browser styles work without a server interpreter?

@davidroeca @westtrade thank you for explaining to me.
I will keep tracking this issue and maybe I find a better approach.

For now, I will close this issue and merge PR #253.
Please, feel free to reopen this issue or open a new one.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikeriley131 picture mikeriley131  ·  8Comments

roryprimrose picture roryprimrose  ·  7Comments

negativefix picture negativefix  ·  7Comments

davedele picture davedele  ·  5Comments

equinusocio picture equinusocio  ·  14Comments