Comment publier un module écrit en ES6 de la NGP?

J'étais sur le point de publier un module NPM, quand j'ai pensé à le réécrire dans l'ES6, à la fois de l'avenir, et apprendre ES6. J'ai utilisé Babel à transpile à l'ES5, et effectuer des tests. Mais je ne suis pas sûr de savoir comment procéder:

  1. Dois-je transpile, et de publier le résultat /dossier de sortie de la NGP?
  2. Dois-je inclure le résultat dans le dossier mon dépôt Github?
  3. Ou dois-je maintenir 2 repos, l'un avec l'ES6 code + gulp script pour Github, et un avec le transpiled résultats + tests pour la NGP?

En bref: quelles sont les étapes que je dois suivre pour publier un module écrit en ES6 de MNP, tout en permettant aux gens de parcourir/fourche le code d'origine?

  • J'ai été aux prises avec cette décision, ces derniers temps. Je vois la réponse que vous avez marqués comme correct par José> étant le consensus.
  • Voici mon 2018 réponse, en tenant compte de l'avancement de la prise en charge du module depuis 2015.
  • J'aimerais, si je pouvais faire le contraire. L'utilisation d'un Module ES pour importer un module NPM, mais ce sont les seuls résultats que j'obtiens.
InformationsquelleAutor Traveling Tech Guy | 2015-04-20
  1. 64

    Le modèle que j'ai vu jusqu'à présent est de garder l'es6 fichiers dans un src répertoire et de créer vos trucs dans des mnp prepublish à la lib répertoire.

    Vous aurez besoin d'une .npmignore fichier similaires à .gitignore, mais ignorant src au lieu de lib.

    • Avez-vous de l'exemple de référentiel?
    • href="https://github.com/jakwuh/di-loader" >github.com/jakwuh/di-loader
    • Notez que vous aurez probablement envie de changer le "début" et de "construire" des commandes dans le package.json à utiliser le chemin relatif de la babel-cli: ./node_modules/babel-cli/bin/babel.js -s inline -d lib -w src. Ce devrait veiller à ce que l'installe de ne pas échouer lors du déploiement de nouveaux environnements.
    • npm gère
    • “Si il n'y a pas .npmignore fichier, mais il y a un .gitignore fichier, puis npm va ignorer les choses en correspondance par l' .gitignore fichier.” officiel de la ngp docs
    • Au lieu de .npmignore vous pouvez utiliser le files champ dans le paquet.json. Il vous permet de spécifier exactement les fichiers que vous souhaitez publier, au lieu de la chasse aux fichiers aléatoires vous ne pas vous voulez publier.
    • J'ai un passe-partout repo qui fait exactement ce qui est mentionné dans cette réponse, et c'est l'approche recommandée ainsi - npm-module standard

    InformationsquelleAutor José F. Romaniello
  2. 63

    J'aime José réponse. J'ai remarqué plusieurs modules de suivre ce motif déjà. Voici comment vous pouvez facilement mettre en œuvre avec Babel6. J'ai installer babel-cli localement afin de la construire ne pas casser si jamais je change mon global babel version.

    .npmignore

    /src/

    .gitignore

    /lib/
/node_modules/

    Installer Babel

    npm install --save-dev babel-core babel-cli babel-preset-es2015

    paquet.json

    {
  "main": "lib/index.js",
  "scripts": {
    "prepublish": "node_modules/babel-cli/bin/babel.js src --out-dir lib"
  },
  "babel": {
    "presets": ["es2015"]
  }
}
    • Toutes les commandes dans le scripts aura node_modules/.bin ajouté à leur $PATH et depuis babel-cli installe un binaire à node_modules/.bin/babel il n'est pas nécessaire à la référence de la commande par le chemin.
    • Veuillez noter que prepublish est problématique, car il pouvait courir au moment de l'installation (github.com/npm/npm/issues/3059), préférez le plus idiomatique version script hook (docs.npmjs.com/cli/version)
    • il me semble que le problème avec prepublish est toujours là. Pour le moment, je pense que la compilation manuelle de la src répertoire et npm publish est le chemin à parcourir.
    • Vous pouvez utiliser prepublishOnly script hook (voir docs.npmjs.com/misc/scripts#prepublish-and-prepare). Notez que dans la version 5 de mnp, cela devrait fonctionner comme prévu, mais pour l'instant (en supposant que vous êtes à l'aide de mnp v4+) cela devrait fonctionner.
    • Je continue à me battre, à laquelle la fin de l'es5 transpilation est censé se produire? – je peux voir des tas de projets, de la construction (directement ou indirectement par l'intermédiaire de construire cible) dans le prepublish script. Mais personne (sauf pour les <1%, je juge en erreur) engage la lib/ dossier, comme je peux le voir dans chaque référentiel... — ainsi prepublish est plus d'une vérification de la syntaxe, pas un pré-rendu (ou: "pré-construit binaires") ?
    • Comment package.json - "files" (docs) interférer avec .npmignore?
    • de la documentation, "même si elles seraient repris par les fichiers de tableau", de sorte que "si, dans les fichiers, et de ne pas en tenir compte", de sorte que vous pourriez, par exemple, ajouter lib à files et *.doc.xml à .npmignore.
    • s'exécute avant publish (obv.), ce qui pousse les choses à mnp (ou partout où vous le configurer). Donc, c'est pour la construction de ce qui se passe dans le package NPM, même si elle n'est pas cochée dans.
    • Un bon article (github.com/bookercodes/articles/blob/master/...) suggère de mettre babel compilation dans le "build" script, lors de l'exécution de "prepublish": "npm run build" ou "yarn build" si votre utilisation yarn à la place.

    InformationsquelleAutor Marius Craciunoiu
  3. 19

    TL;DR - Ne le faites pas, jusqu'à ~octobre 2019. L'Node.js Les Modules De L'Équipe a demandé:

    Merci de ne pas publier tout ES les paquets de modules destinés à l'usage Node.js jusqu'à ce que [octobre 2019]

    2019 Peut mettre à jour

    Depuis 2015, lorsque cette question a été posée, le support de JavaScript pour les modules a beaucoup évolué, et je l'espère, sera officiellement stable en octobre 2019. Toutes les autres réponses sont maintenant obsolètes ou trop compliqué. Voici la situation actuelle et les meilleures pratiques.

    ES6 soutien

    99% de l'ES6 (aka 2015) a été pris en charge par le Nœud depuis la version 6. La version actuelle de Nœud est de 12. Tous evergreen navigateurs prennent en charge la grande majorité des ES6 fonctionnalités. ECMAScript est maintenant à version 2019, et le schéma de gestion des versions privilégie désormais l'aide d'années.

    ES Modules (aka ECMAScript modules) dans les navigateurs

    Tous evergreen navigateurs ont été l'appui import-ing ES6 modules depuis 2017. Dynamique des importations sont pris en charge par Chrome (+ fourche comme l'Opéra et le Samsung Internet) et Safari. Assistance de Firefox est prévue pour la prochaine version, 67.

    Vous n'avez plus besoin Webpack/cumulatif/Colis etc. pour le chargement des modules. Ils peuvent encore être utiles à d'autres fins, mais ne sont pas requis pour charger votre code. Vous pouvez importer directement des URLs pointant vers ES des modules de code.

    ES modules Nœud

    ES modules (.mjs fichiers avec import/export) ont été pris en charge depuis le Nœud v8.5.0 en appelant node avec le --experimental-modules drapeau. Nœud v12, sorti en avril 2019, a réécrit les modules expérimentaux de soutien. La partie la plus visible du changement, c'est que l'extension du fichier doit être spécifié par défaut lors de l'importation:

    //lib.mjs 

export const hello = 'Hello world!';

//index.mjs:

import { hello } from './lib.mjs';
console.log(hello);

    Note obligatoires .mjs extensions de partout. Exécuter en tant qu':

    node --experimental-modules index.mjs

    Le Nœud 12 version est également lorsque les Modules de l'Équipe demandé développeurs de ne pas publier ES paquets de module conçu pour une utilisation par Node.js jusqu'à ce qu'une solution soit trouvée pour l'utilisation de paquets via les deux require('pkg') et import 'pkg'. Vous pouvez toujours publier natif ES modules destiné aux navigateurs.

    Le soutien des écosystèmes indigènes ES modules

    En Mai 2019, le soutien des écosystèmes pour ES Modules est immature. Par exemple, un test de cadres comme La blague et Ava ne prennent pas en charge --experimental-modules. Vous devez utiliser un transpiler, et doit alors décider entre l'utilisation de la nommée à l'importation (import { symbol }) syntaxe (qui ne fonctionne pas avec la plupart des packages npm encore), et l'importation par défaut de syntaxe (import Package from 'package'), qui fonctionne, mais pas quand Babel analyse pour les paquets rédigé en caractères d'imprimerie (graphql-outils, noeud à l'afflux, faast etc.) Il y a cependant une solution qui fonctionne à la fois avec --experimental-modules et si Babel transpiles votre code, de sorte que vous pouvez le tester avec Jest/Ava/Moka etc:

    import * as ApolloServerM from 'apollo-server'; const ApolloServer = ApolloServerM.default || ApolloServerM;

    Sans doute moche, mais de cette façon, vous pouvez écrire votre propre ES des modules de code avec import/export et de l'exécuter avec node --experimental-modules, sans transpilers. Si vous avez des dépendances qui ne sont pas ESM-encore prêt, les importer comme ci-dessus, et vous serez capable d'utiliser des frameworks de test et d'outillage d'autres via Babel.

    Précédente réponse à la question - n'oubliez pas, ne pas faire ceci jusqu'à ce que le Nœud résout le besoin/l'importation de la question, espérons-le, vers le mois d'octobre 2019.

    Publication ES6 modules npm, avec rétro-compatibilité

    De publier un module ES à npmjs.org de sorte qu'il peut être importés directement, sans Babel ou d'autres transpilers, il suffit de pointer le main champ dans votre package.json à la .mjs fichier, mais omettre l'extension:

    {
  "name": "mjs-example",
  "main": "index"
}

    C'est le seul changement. En omettant l'extension, le Noeud va d'abord regarder pour une mjs fichier si vous exécutez avec --expérimental-modules. Sinon, il reviendra à la .js fichiers, de sorte que votre transpilation processus de soutenir les anciens Nœud versions fonctionnera comme avant — assurez-vous simplement au point de Babel à la .mjs fichier(s).

    Voici la source pour un natif module ES avec rétro-compatibilité pour le Noeud < 8.5.0 que j'ai publié pour la NGP. Vous pouvez l'utiliser dès maintenant, sans Babel ou quoi que ce soit d'autre.

    Installer le module:

    npm install local-iso-dt
# or, yarn add local-iso-dt

    Créer un fichier de test test.mjs:

    import { localISOdt } from 'local-iso-dt/index.mjs';
console.log(localISOdt(), 'Starting job...');

    Exécuter nœud (v8.5.0+) avec l' --expérimental-modules drapeau:

    node --experimental-modules test.mjs

    Tapuscrit

    Si vous développer à la Machine, vous pouvez générer ES6 code et l'utilisation ES6 modules:

    tsc index.js --target es6 --modules es2015

    Ensuite, vous devez renommer *.js sortie de .mjs, connu question qui nous l'espérons, se fixe bientôt donc, tsc de sortie peut .mjs fichiers directement.

    • En disant "Tous les evergreen navigateurs prennent en charge la grande majorité des ES6 fonctionnalités." ne veut pas dire grand-chose quand vous regardez le data et de réaliser que es6 support dans les navigateurs n'atteint qu'environ 80% de tous les utilisateurs.
    • Actuellement, l'écosystème n'est certainement pas assez mature pour cela. L'Node.js l'équipe avec la sortie de v12 spécifiquement demandé: "Merci de ne pas publier tout ES les paquets de modules destinés à l'usage Node.js jusqu'à ce que soit résolu." 2ality.com/2019/04/nodejs-esm-impl.html#es-modules-on-npm Moka ne prend pas en charge en mode natif .mjs fichiers. De nombreuses de nombreuses bibliothèques (par exemple, créer-réagir-app, réagissent-apollo, graphql-js) eu des problèmes de dépendances contenant mjs fichiers. Node.js les plans de déploiement de soutien officiel en octobre 2019, la plus ancienne, je voudrais sérieusement de revoir tout cela.
    • merci pour le rappel de mise à jour de ce vieux la réponse! Juste fait.
    InformationsquelleAutor Dan Dascalescu
  4. 16

    @Jose est à droite. Il n'y a rien de mal avec la publication ES6/ES2015 de MNP, mais qui peut causer des problèmes, spécialement si la personne à l'aide de votre colis à l'aide de Webpack, par exemple, parce que, normalement, les gens ignorent le node_modules dossier alors que le prétraitement avec babel pour des raisons de performances.

    Donc, il suffit d'utiliser gulp, grunt ou tout simplement Node.js pour construire un lib dossier ES5.

    Voici mon build-lib.js script, que je garde dans ./tools/ (pas de gulpou grunt ici):

    var rimraf = require('rimraf-promise');
var colors = require('colors');
var exec = require('child-process-promise').exec;

console.log('building lib'.green);

rimraf('./lib')
    .then(function (error) {
        let babelCli = 'babel --optional es7.objectRestSpread ./src --out-dir ./lib';
        return exec(babelCli).fail(function (error) {
            console.log(colors.red(error))
        });
    }).then(() => console.log('lib built'.green));

    Voici un dernier conseil: Vous besoin d'ajouter un .npmignore à votre projet. Si npm publish ne trouve pas ce fichier, il va utiliser .gitignore au lieu de cela, ce qui va vous causer des ennuis parce que, normalement, votre .gitignore fichier exclure ./lib et comprennent ./src, ce qui est exactement le contraire de ce que vous voulez quand vous êtes à la publication de MNP. Le .npmignore fichier est fondamentalement la même syntaxe de .gitignore (autant que je sache).

    • Merci pour le point sur .gitignore et .npmignore.
    • Au lieu de .npmignore vous pouvez utiliser le files champ dans le paquet.json. Il vous permet de spécifier exactement les fichiers que vous souhaitez publier, au lieu de la chasse aux fichiers aléatoires vous ne pas vous voulez publier.
    • L'habitude de cette rupture de l'arbre qui tremble?
    • Je ne recommande pas l'utilisation .npmignore, essayez package.json's files au lieu de cela, voir: github.com/c-hive/guides/blob/master/js/...
    • c'est exactement ce que j'ai recommandé dans mon commentaire ci-dessus..?
    • Mon mauvais, n'est-ce pas d'avis 🙂

    InformationsquelleAutor André Pena
  5. 5

    Si vous voulez le voir en action dans un très simple petit open source Nœud du module, puis jetez un oeil à nième jour (que j'ai commencé - aussi d'autres contributeurs). Regardez dans le package.fichier json et à la prepublish étape qui vous conduira à l'endroit où et comment le faire. Si vous clonez ce module vous pouvez l'exécuter localement et l'utiliser comme un modèle pour yous.

    InformationsquelleAutor Guy
  6. 3

    Les deux critères d'un mécanisme national de prévention paquet est qu'il est utilisable avec rien de plus qu'un require( 'package' ) et fait quelque chose de logiciels-ish.

    Si vous remplissez ces deux conditions, vous pouvez faire ce que vous souhaitez.
    Même si le module est écrit dans l'ES6, si l'utilisateur final n'a pas besoin de savoir ça, je transpile pour l'instant pour obtenir le maximum de soutien.

    Cependant, si comme koa, votre module nécessite la compatibilité avec les utilisateurs en utilisant ES6 fonctions, alors peut-être les deux solution serait une meilleure idée.

    Emporter

    1. Seulement de publier autant de code que vous avez besoin de faire require( 'your-package' ) travail.
    2. À moins que l'entre ES5 & 6 des questions à l'utilisateur, seulement publier 1 paquet. Transpile si vous devez.
    • Cela ne semble pas répondre à la question. Je pense que l'OP est à essayer de comprendre comment la structure de leur dépôt Github et que de publier de MNP et tout ce que vous avez dit, c'est qu'ils peuvent faire ce qu'ils veulent. L'OP veut des recommandations spécifiques sur une bonne pratique de cette situation.
    • Je suis en désaccord. J'ai recommandé qu'il transpile, et publier uniquement les fichiers qui sont nécessaires pour require( 'package' ) de travail. Je vais modifier ma réponse pour que cela soit plus clair. Cela dit, Jose réponse est beaucoup mieux que la mienne.
    • José réponse est très bonne, mais j'apprécie c'est explicitement décrivant les bonnes règles de base pour quand/pourquoi utiliser un ou deux paquets.
    • Pas besoin d'utiliser deux paquets.
    InformationsquelleAutor JoshWillik
  7. 3

    La clé principale dans package.json décide le point d'entrée du colis une fois qu'il est publié. Ainsi, vous pouvez mettre votre Babel de sortie où vous voulez, suffit de mentionner le droit chemin en main clé.

    "main": "./lib/index.js",

    Voici un bien écrit l'article sur la façon de publier un package npm

    https://codeburst.io/publish-your-own-npm-package-ff918698d450

    Voici un exemple de pensions de titres que vous pouvez utiliser pour référence

    https://github.com/flexdinesh/npm-module-boilerplate

    InformationsquelleAutor Dinesh Pandiyan
  8. 0

    Deppending sur l'anatomie de votre module, cette solution peut ne pas fonctionner, mais si votre module est contenues à l'intérieur d'un seul fichier, et n'a pas de dépendances (ne pas utiliser de importation), en utilisant le modèle suivant, vous pouvez libérer votre code tel qu'il est, et sera en mesure d'être importés avec importation (Navigateur ES6 Modules) et besoin (Nœud de CommonJS Modules)

    Comme un bonus, il sera suittable être importés à l'aide d'un SCRIPT de l'Élément HTML.

    main.js :

    (function(){
    'use strict';
    const myModule = {
        helloWorld : function(){ console.log('Hello World!' )} 
    };

    //if running in NODE export module using NODEJS syntax
    if(typeof module !== 'undefined') module.exports = myModule ;
    //if running in Browser, set as a global variable.
    else window.myModule = myModule ;
})()

    my-module.js :

        //import main.js (it will declare your Object in the global scope)
    import './main.js';
    //get a copy of your module object reference
    let _myModule = window.myModule;
    //delete the the reference from the global object
    delete window.myModule;
    //export it!
    export {_myModule as myModule};

    paquet.json :`

        {
        "name" : "my-module", //set module name
        "main": "main.js",  //set entry point
        /* ...other package.json stuff here */
    }

    Pour utiliser votre module, vous pouvez maintenant utiliser la syntaxe normale ...

    Lorsqu'ils sont importés dans NŒUD ...

        let myModule = require('my-module');
    myModule.helloWorld();
    //outputs 'Hello World!'

    Lorsqu'ils sont importés dans NAVIGATEUR ...

        import {myModule} from './my-module.js';
    myModule.helloWorld();
    //outputs 'Hello World!'

    Ou même lorsqu'ils sont inclus à l'aide d'un Élément de Script HTML...

    <script src="./main.js"></script>
<script>
     myModule.helloWorld();
    //outputs 'Hello World!'
</script>
    InformationsquelleAutor colxi
  9. -1

    Quelques notes supplémentaires pour quiconque, à l'aide de propre modules directement à partir de github, ne passant pas par publié modules:

    L' (largement utilisé) "prepublish" crochet n'est pas de faire rien pour vous.

    Meilleure chose que l'on peut faire (si les plans de compter sur github repos, non publié trucs):

    • unlist src de .npmignore (en d'autres mots: l'autoriser). Si vous n'avez pas de .npmignore, rappelez-vous: Une copie de .gitignore sera utilisé à la place de l'emplacement d'installation, comme ls node_modules/yourProject vais vous montrer.
    • assurez-vous, babel-cli est un depenency dans votre module, et pas seulement un devDepenceny puisque vous êtes en effet bâtiment sur la consommation de la machine aka au développeurs d'applications de l'ordinateur, qui est à l'aide de votre module

    • ne l'accumulation chose, dans le installer le crochet c'est à dire:

      "install": "babel src -d lib -s"

    (pas d'ajout de valeur à rien d'essayer de "pré-installer", c'est à dire babel-cli est peut-être manquant)

    • Compiler sur installer, c'est très impoli. Merci de ne pas faire ce mnp le temps d'installation est assez mauvais! Pour les internes de code où vous souhaitez éviter l'utilisation d'un mécanisme de prévention dépôt de paquets, vous pouvez: 1) utiliser un monorepo, 2) Télécharger et dépendent npm pack de sortie, 3) vérifier à la sortie de la construction.
    InformationsquelleAutor Frank Nocke