Milligram: Supprimer la propriété des moteurs de package.json

@westtrade Milligram a été mis à niveau vers la version LTS de Node.js, car il s'agit d'une pratique fortement recommandée pour maintenir toutes les dépendances à jour.

S'il vous plaît, pouvez-vous expliquer en détail pourquoi Milligram a besoin de Node.js v11 ?

Je viens de tomber sur ce problème moi-même. Actuellement sur le nœud 14, à la pointe de la technologie, et en utilisant svelte , qui est également à la pointe de la technologie. En tant qu'utilisateur, il est un peu étrange d'avoir un framework css uniquement qui me dise sur quel moteur de nœud je suis censé être. Je suppose que ce drapeau de moteur est plus utile pour les développeurs de milligram lui-même ?

Une solution de contournement facile à ce problème dans le fil est yarn add --ignore-engines milligram , et dites à toute personne qui clone votre repo vers yarn install --frozen-lockfile --ignore-engines plutôt que juste yarn install --frozen-lockfile . Cependant, ce n'est pas idéal, étant donné que tout ce que j'importe est css.

@davidroeca Oui. La version Node.js est définie car elle est requise pour l'environnement de développement du Milligram. En outre, il est fortement recommandé de maintenir toutes les dépendances à jour. Dans ce cas, Milligram utilise la version LTS (v12) de Node.js.

Alors, laissez-moi mieux comprendre ce qui se passe et peut-être que nous pouvons aider à l'améliorer.

@cjpatoilo Je suis d'accord qu'il est préférable de garder les packages à jour. Je suis en fait plus à jour que la v12. Mon problème est légèrement différent de celui de >= pour permettre également les futures versions des nœuds :

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

Une discussion similaire a eu lieu dans le repo bootstrap . Ils ont choisi de supprimer entièrement le champ des moteurs, car ces moteurs spécifiques ne sont nécessaires que pour créer le dossier dist/ que les utilisateurs utilisent. Cela se produit lors de l'étape de construction, donc je n'ai en fait besoin de rien en rapport avec JS pour télécharger ces fichiers.

Du point de vue du développement dans ce référentiel, une note dans le README spécifiant la version du nœud pris en charge + un environnement CI avec une version du nœud épinglé suffit-il à cet égard ?

@westtrade @davidroeca pour l'instant, je vais supprimer engine de package.json

@davidroeca @westtrade s'il vous plaît, pouvez-vous me dire ce qui se passe lorsque vous installez Milligram ?

Je sais que nous avons 2 excellents exemples, et si je comprends bien, le premier exemple utilise une version avant LTS et le deuxième exemple utilise une version après LTS, et les deux exemples sont affectés.

Tout d'abord, je voudrais savoir si le même comportement se produit lors de l'utilisation de Yarn et Npm.

D'ailleurs, le même comportement se produit lorsque vous utilisez ou installez Milligram v1.4.0 et v1.3.0 (dernières versions) ?

Avec npm, j'obtiens les avertissements suivants :

❯ 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

Avec du fil, c'est une erreur :

❯ 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.

Descente à 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

Avec du fil :

❯ 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.

Avec milligram@~1.3.0 , je peux utiliser la dernière version de nodejs sans problème :

❯ 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 s'il vous plaît, pouvez-vous me dire ce qui se passe lorsque vous installez Milligram ?

Je sais que nous avons 2 excellents exemples, et si je comprends bien, le premier exemple utilise une version avant LTS et le deuxième exemple utilise une version après LTS, et les deux exemples sont affectés.

Tout d'abord, je voudrais savoir si le même comportement se produit lors de l'utilisation de Yarn et Npm.

D'ailleurs, le même comportement se produit lorsque vous utilisez ou installez Milligram v1.4.0 et v1.3.0 (dernières versions) ?

Dans mon cas, il ne s'installe tout simplement pas et NPM renvoie une erreur que j'ai écrite dans le titre. Votre framework est merveilleux - mais il est étrange que le framework de style nécessite une version d'interpréteur de serveur. Les styles de navigateur ne fonctionneraient-ils pas sans un interpréteur de serveur ?

@davidroeca @westtrade merci de m'avoir expliqué.
Je vais continuer à suivre ce problème et peut-être trouverai-je une meilleure approche.

Pour l'instant, je vais fermer ce problème et fusionner le PR #253.
N'hésitez pas à rouvrir ce problème ou à en ouvrir un nouveau.