Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:37
    zkochan commented #4278
  • 07:05
    Shinigami92 labeled #4278
  • 07:05
    Shinigami92 opened #4278
  • 02:06
    devie2020 commented #4272
  • Jan 24 22:38
    imsys commented #4190
  • Jan 24 22:36
    imsys commented #4190
  • Jan 24 18:44
    jeremymeng commented #4274
  • Jan 24 12:33
    xiamu33 commented #4208
  • Jan 24 09:33
    polRk commented #3952
  • Jan 24 09:32
    polRk commented #3952
  • Jan 24 03:13
    JiuXi-331 commented #4263
  • Jan 23 21:43

    zkochan on v7

    chore(deps): update chore(deps): update chore(release): 6.28.0 and 1 more (compare)

  • Jan 23 21:41

    zkochan on v6.28.0

    (compare)

  • Jan 23 21:41

    zkochan on main

    chore(deps): update chore(release): 6.28.0 (compare)

  • Jan 23 21:21

    zkochan on main

    chore(deps): update (compare)

  • Jan 23 15:57
    realfresh commented #3114
  • Jan 23 15:57
    realfresh commented #3114
  • Jan 23 15:57
    realfresh commented #3114
  • Jan 23 15:56
    realfresh commented #3114
  • Jan 23 15:56
    realfresh commented #3114
Andrey Popp
@andreypopp
btw lockfiles
I like that npm5 locks the structure — I think it's more readable than yarn's approach where it maps ranges to concrete versions
The improvement, I think would be to have a flat structure like yarn but with dependent: package-name field on each record which specifies the package which depends on the record's package
Zoltan Kochan
@zkochan
Zoltan Kochan
@zkochan
I'll write a post about pnpm's shrinkwrap format. But ours doesn't need to fix layout because pnpm is not hoisting packages.
our's is also good for CR because we use YAML not JSON
and we show structure, by having dependencies and optionalDependencies in each package. So no need in dependent
Zoltan Kochan
@zkochan
Andrey Popp
@andreypopp
🎉🎉👍
kylemeier
@kylemeier
sorry if this was already asked but if one library requires lodash 1.5.4 and another lodash 2.7.9, does lodash get installed twice or just once and potentially breaks one of the libraries?
Zoltan Kochan
@zkochan
By once we mean. Once a concrete version
So both 1.5.4 and 2.7.9 will be installed. But only once each
Jason Yu
@ycmjason
hello there, I have a curious question. Is there a way to see which packages are available on local, i.e. already downloaded on my computer?
Zoltan Kochan
@zkochan
there is no command for it. You can look in the ~/.pnpm-store/2/store.json file
Jason Yu
@ycmjason
wouldn't it be a neat feature?
pnpm ls
then list the packages installed locally
Zoltan Kochan
@zkochan
we did not implement pnpm ls yet:-)
Jason Yu
@ycmjason
just a suggestion or random thought
Zoltan Kochan
@zkochan
oh, look, we already had this idea pnpm/pnpm#430
pnpm store ls
Zoltan Kochan
@zkochan
pnpm is now on 1st page when Google searching "fast package manager". And on first place on duckduckgo :tada:
kaiserfedor
@kaiserfedor
Hello everyone! In pnpm doc: When using npm or Yarn for example, if you have 100 packages using lodash, you will have 100 copies of lodash on disk. But it doesn't seem to be true, at least for npm. :)
it may confuse somebody
Zoltan Kochan
@zkochan
OK. I'll rewrite it.
kaiserfedor
@kaiserfedor
Thank you for your work.
Zoltan Kochan
@zkochan
so I guess I'll just replace "packages" with "projects".
inside packages dependencies duplicate as well. but that would be harder to explain in a sentence
if you have 100 projects using lodash
kaiserfedor
@kaiserfedor
:+1:
schemelev
@schemelev
has anyone been faced with the transfer of the node_modules folder to another
Zoltan Kochan
@zkochan
what do you mean?
schemelev
@schemelev
Install packages and build the project (Teamcity) occur in the temporary folder. And if successful, the project folder is transferred to a working folder.
Zoltan Kochan
@zkochan
pnpm uses symlinks. They are relative.
so I think if the temp folder is on the same level of nesting as the destination folder then it is fine
symlinks should work in the destination folder
otherwise, you can use a store that will be inside the temp folder as well
and in that case the project will be moved together with the store
but I am not sure I tried it. Maybe symlinks are fixed during folder moves? I don't know. Let us know about your findings
schemelev
@schemelev
Thank you, I will look for a solution
Zoltan Kochan
@zkochan
by the way, there are some ideas how to make pnpm faster on CI servers. For instance, we can skip integrity checks, as nobody would mutate packages in a CI store pnpm/pnpm#803
schemelev
@schemelev
On Windows after move the folder node_nodules links are broken. On Ubuntu after move node_nodules links work correctly
Zoltan Kochan
@zkochan
on Windows junctions are used
weird
junctions contain the absolute paths, so I though they would work after move
Zoltan Kochan
@zkochan
if that would help, we can add an option to use symlinks on Windows.
they are not used by default because symlinks on Windows require admin permissions
but if your CI is a Windows, you can probably configure it to work fine with symlinks
Zoltan Kochan
@zkochan

@/all pnpm version 1.3 is out

It is 5% faster than 1.2 and has a nice new summary of added/deleted root dependencies:

Imgur

all the changes here

Fox George Penguin
@olstenlarck
@zkochan cool, that summary seems great! :)
Zoltan Kochan
@zkochan
:tada:
Zoltan Kochan
@zkochan

pnpm list implemented in v1.5.

The new command was implemented in pnpm-list and required in the main package

Andrei Neculau
@andreineculau

[WARN] long wall of text coming up

I didn't know about pnpm until today actually, but it sure sounds great :clap: .
Before I give it a shot in my team, I wonder if you have already solved the following problem: creating a deployable bundle that is space-optimized when unpacked (the archive compressor would take care of most of the duplication, but we have limited disk space when unpacking the bundle).

A bit of context is that today we do something similar to pnpm (i.e. we don't use npm install the regular way, and use symlinks to gain speed) and at build-artifact step, we actually do a full copy and call npm dedupe <rant>npm@3 actually, since that's the only one that still works properly...</rant>
AFAICS using pnpm, instead of our install setup, should work just as well, and then we could still do a full copy (i.e. no hardlinks) and call npm dedupe.
But do you (pnpm users or pnpm itself) have anything to aid the need for a deduped node_modules ? Thanks!