95 Matching Annotations
  1. Last 7 days
  2. Oct 2020
  3. 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?
  4. Apr 2020
  5. 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.
  6. Nov 2019
  7. Oct 2019
  8. 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.
  9. 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.
  10. Apr 2019
  11. 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.

  12. Oct 2018
  13. Aug 2018
  14. May 2018
  15. 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.

  16. 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!

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