149 Matching Annotations
  1. Mar 2024
  2. Aug 2023
    1. If you want to mimic a more production like situation you might use this workflow: Create a package of your submodule locally: cd /path/to/your/module npm pack This will create a .tgz file of your package in /path/to/your/module Install the local package of the submodule in your application: cd /path/to/your/application npm install /path/to/your/module/<YourModule>-<YourModulesVersion>.tgz
  3. Jul 2023
  4. Jun 2023
  5. Mar 2023
  6. Feb 2023
  7. Nov 2022
  8. Jun 2022
  9. May 2022
    1. I develop in Node and Sveltekit regularly and the chances that on any given day my flow might be crushed by random madness is unacceptably high.
    1. Not only this. Try to change the app two years later. Dependencies gone, wrong NPM version, Webpack config depricated and what not.That's why I like to use vanilla JS as much as possible. It will be maintainable years later.
  10. Apr 2022
  11. Jan 2022
    1. {
       "@context": {
        "doap": "http://usefulinc.com/ns/doap#",
        "url": "@id",
        "name": "doap:name",
        "description": "doap:description",
        "author": "doap:maintainter",
        "license": "doap:license", // can we map values to https://spdx.org/licenses/ ?
        ...
        },
        "homepage": {"@id": "doap:homepage", "@type": "@id"}
      }
      
    1. [...] In short, pinning dependencies means the exact version specified will be installed, rather than a dependency matching the range criteria. Here's an example:

      {
        "dependencies": {
          "react": "17.0.2", // installs react@17.0.2 exactly. I recommend this.
          "react": "^17.0.2", // installs the latest minor version after .0 (so 17.*.*)
          "react": "~17.0.2" // installs the latest patch after .2 (so 17.0.*)
        }
      }
      

      To automatically accomplish this in your projects, you can add save-exact=true to a .npmrc file, or use --save-exact when adding the dependency via npm (or --exact via yarn).

  12. Jun 2021
    1. npm install <folder>: Install the package in the directory as a symlink in the current project. Its dependencies will be installed before it's linked. If <folder> sits inside the root of your project, its dependencies may be hoisted to the top-level node_modules as they would for other types of dependencies.
    1. The answer for me is @whitecolor's yalc.
    2. But this solution has technical complications, and the npm and the yarn implimentations give people trouble (as of this writing there are about 40 open npm link issues and over 150 open yarn link issues). If you have tried to use symlinked dependencies while developing a package you've probably run into into a stumbling block, whether simply an unexpected unlink behavior, trouble with peer dependencies, or something bigger.
  13. May 2021
    1. What is that npx thing? npx ships with npm and lets you run locally installed tools. We’ll leave off the npx part for brevity throughout the rest of this file! Note: If you forget to install Prettier first, npx will temporarily download the latest version. That’s not a good idea when using Prettier, because we change how code is formatted in each release! It’s important to have a locked down version of Prettier in your package.json. And it’s faster, too.
  14. Mar 2021
    1. You might get the impression after reading David's article above that this trend arose from lazy developers who "forgot how to program", but the reality is that the tiny-module ecosystem on NPM was the intention from the beginning
  15. Feb 2021
  16. Jan 2021
  17. Dec 2020
    1. Does anyone know how to make npm use a specific fork containing a bug fix while waiting for maintainer to merge a pull request? I was just going to point my package.json to this fork, like this: "svelte-material-ui": "https://github.com/vtpatrickeddy/svelte-material-ui.git#patch-1", but that doesn't work because the repo is a monorepo. And there doesn't appear to be a way to specify a subdirectory inside it, like: "@smui/textfield": "https://github.com/vtpatrickeddy/svelte-material-ui.git/packages/textarea#patch-1",
  18. Oct 2020
  19. Sep 2020
    1. From npm@5.2.0, npm ships with npx package which lets you run commands from a local node_modules/.bin or from a central cache.
    2. By default, npx will check whether <command> exists in $PATH, or in the local project binaries, and execute that. Calling npx <command> when <command> isn't already in your $PATH will automatically install a package with that name from the NPM registry for you, and invoke it. When it's done, the installed package won’t be anywhere in your globals, so you won’t have to worry about pollution in the long-term. You can prevent this behaviour by providing --no-install option.
    1. Something to be aware of when you’re using any bundler: there’s very little consistency when it comes to how modules are packaged in NPM. It’s incredibly frustrating, especially considering many of us write modules these days using ESM. Here’s some various problems that come up:
    1. But this is only a halfway decent way to clarify that this is an external dependency, because the only way to resolve a peer dependency warning is to install react from npm—there's no way to notify npm that you resolve the dependency to a browser global. So peer dependencies should be avoided in favor of external declarations. Then Rollup will take care of warning about "unresolved dependencies", even if external declarations can't express a particular version range with which your library is compatible like peer dependencies can.

      Interesting. Didn't realize. From my perspective, I usually do install packages via npm, so wouldn't have known about this problem.

      npm and rollup both try to solve this problem but in different ways that apparently conflict? So if a lib author lists peerDependencies then it can cause problems for those getting lib via browser (CDN)? How come so many libs use it then? How come I've never heard of this problem before?

    1. We must always return at least some validation rule. So first off if value !== undefined then we'll return our previous validation schema. If it is undefined then we'll use the yup.mixed().notRequired() which will just inform yup that nothing is required at the optionalObject level. optionalObject: yup.lazy(value => { if (value !== undefined) { return yup.object().shape({ otherData: yup.string().required(), }); } return yup.mixed().notRequired(); }),
    1. For everyone else, npm run build will bundle your component's source code into a plain JavaScript module (dist/index.mjs) and a UMD script (dist/index.js). This will happen automatically when you publish your component to npm, courtesy of the prepublishOnly hook in package.json.
    1. For a non-monorepo package you can simply point directly to the Github repo. This case is similar, but you want to scope it just to a single package within the repo. For those that make monorepos they don't necessarily need this feature. It's for those that use projects that use monorepos. Telling them to not organize their projects into monorepos doesn't help people who make use of these projects.
    2. If npm installs a git repo, it assumes that the git repo is the package. I don't really know how we could specify a sub-path easily, since all parts of the git url are already used for other things.
    1. This is more a rhetoric question as this seems to be quite hard ;-) There is a long discussion about installing a subfolder of a repository and monorepos in general at the NPM Github issues (yarn misses this feature, too). The thing is that this makes it quite hard to report issues of your project as one can't test the current master easily. Do you recommend a way how to use the latest Github version?
  20. Apr 2020
  21. Dec 2019
    1. GitHub Packages uses the native package tooling commands you're already familiar with to publish and install package versions.

      Looks like GitHub Packages acts as a wrapper to these clients, acting on your behalf so you don't have to use the CLI yourself.

    1. But what you absolutely should do is test your NPM package in its published format. Create some smoke tests that reside in the actual codebase, but are not part of the test suite.
  22. Nov 2019
  23. Oct 2019
  24. Sep 2019
    1. NPM was not and is still not designed to specifically be a node package manager. Yes it has a lot of useful features supporting node.js (some like node_modules is even hardcoded in node.js) but it actually doesn't care what language your software is written in. It is a package manager for your OS, just like apt and yum (or brew for you Mac users).
    2. This is because it's not a node-specific package manager so what it installs could be a Python script or a shell script or a binary executable written in assembly.
  25. Aug 2019
    1. prepare: Run both BEFORE the package is packed and published, on local npm install without any arguments, and when installing git dependencies
    1. With now more than 3000 modules, there are huge gaps in the quality of things you find in the npm registry. But more often than not, it's easy to find a module that is really close to what you need, except if it wasn't for that one bug or missing feature.
  26. Apr 2019
  27. Nov 2018
    1. As a package manager, a large part of npm's job when installing your dependencies is managing their versions. But its usual model, with a "dependencies" hash in package.json, clearly falls down for plugins. Most plugins never actually depend on their host package, i.e. grunt plugins never do require("grunt"), so even if plugins did put down their host package as a dependency, the downloaded copy would never be used. So we'd be back to square one, with your application possibly plugging in the plugin to a host package that it's incompatible with.

      in other words, a peer dependency enables a kind of reverse dependency. so a plugin to appA can this way 'require' that appA would be of a specific version, not as its own dependency but rather as a neighbour or parent package.

  28. Oct 2018
  29. Aug 2018
  30. May 2018
  31. Jul 2017
    1. The npm client installs dependencies into the node_modules directory non-deterministically. This means that based on the order dependencies are installed, the structure of a node_modules directory could be different from one person to another. These differences can cause “works on my machine” bugs that take a long time to hunt down.

      This is why you should version control your package-lock.json.

  32. Jun 2017
    1. npm start

      If you've followed the tutorial thusfar you will note that there is no 'start' script. npm run dev should work here!

  33. Dec 2015
    1. We shouldn't be expected to get things right the first time, but we need a platform that lets us get it wrong first, and then iterate towards perfection.
    2. I highly recommend giving it a read.

      Ditto, this is a very well constructed argument in favor of small modules.

      Unfortunately however, the current tendency to couple project infrastructure structure (Git repository, issue tracker etc.) to npm project structure doesn't suit this well.