150 Matching Annotations
  1. May 2024
    1. Important for installing npm -g whatever

      mkdir ~/.npm-global

      npm config set-prefix '~/.npm-global'

      export PATH=~/.npm-global/bin:$PATH

      (Basically add to the path)

      source ~/.bashrc

  2. Mar 2024
  3. 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
  4. Jul 2023
  5. Jun 2023
  6. Mar 2023
  7. Feb 2023
  8. Nov 2022
  9. Jun 2022
  10. 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.
  11. Apr 2022
  12. 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).

  13. 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.
  14. 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.
  15. 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
  16. Feb 2021
  17. Jan 2021
  18. 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",
  19. Oct 2020
  20. 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?
  21. Apr 2020
  22. 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.
  23. Nov 2019
  24. Oct 2019
  25. 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.
  26. 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