Add yarn option to asinit

[19h]

asinit should have an option to bypass npm entirely and instead use yarn for all options (including the scripts in the package.json).

[dcodeIO]

Afaik yarn should be mostly compatible with a standard package.json. Could you elaborate a bit what's not working?

[19h]

There isn't anything broken, this is just a feature request :-)

asinit produces a package.json file where the scripts explicitly call npm. My suggestion was to add somthing like --yarn as argument so that all scripts in the package.json file use yarn instead of npm.

[dcodeIO]

Thanks, I see, npm run asbuild runs npm run asbuild:untouched && npm run asbuild:optimized. Is there maybe a portable way that works with both pms?

[ExE-Boss]

If we’re going to support yarn, then we should also support pnpm, which is the third largest node package manager.

[webmaster128]

There is packages like yarpm or yarn-or-npm, which come at the cost of an additional dev dependency. $npm_execpath seems to do the job on Linux and Mac.

I'd be in favour of letting asinit set that when it is runs. It is easy to change manually later on.

[MaxGraey]

npm v7 will be compatible and sync with yarn.lock so I hope it solve all problems

[dcodeIO]

Closing this issue as part of 2020 vacuum because it seems unlikely to be picked up, and this would establish a case to support all sorts of package managers even though npm does fine, and is present on a system with node anyway.

[arcanis]

npm v7 will be compatible and sync with yarn.lock so I hope it solve all problems

It won't, and this thread should be reopened imo. Regardless of what npm says about their next major, they will not support the way Yarn does its installs, nor should you expect them to do it. Tools are different for a reason, and cannot be swapped at will - they will differ in ever so subtle ways. I can even find a few right now:

• Yarn supports plugins that detect scripts being called and wrap their environments (for instance, we use that at work to monitor which scripts are used, and how much time they take - it's really useful to find out the slowest parts of our tooling). Using npm to run a script won't support that, so users will get incomplete metrics.

• Npm doesn't support PnP. The scripts they run don't know where are located the binaries. It usually will work because the parent Yarn process will have put the processes into the PATH, so regardless of what npm sets they should be available, but that's still not a good practice as things work mostly by accident.

• Running the build command with Yarn currently generates the current output - not a great experience to see 12 lines of npm debug when running a command that Yarn would run in ... 0 😅

❯ yarn asbuild

npm WARN lifecycle The node binary used for scripts is /private/var/folders/2s/1qvdx9f97plgcgy4r6mr26x80000gn/T/xfs-92ad9562/node but npm is using /Users/mael.nison/.fnm/node-versions/v12.16.0/installation/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> tmp.o3hzAhlCEm@ asbuild:untouched /private/var/folders/2s/1qvdx9f97plgcgy4r6mr26x80000gn/T/tmp.o3hzAhlCEm
> asc assembly/index.ts --target debug

npm WARN lifecycle The node binary used for scripts is /private/var/folders/2s/1qvdx9f97plgcgy4r6mr26x80000gn/T/xfs-92ad9562/node but npm is using /Users/mael.nison/.fnm/node-versions/v12.16.0/installation/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> tmp.o3hzAhlCEm@ asbuild:optimized /private/var/folders/2s/1qvdx9f97plgcgy4r6mr26x80000gn/T/tmp.o3hzAhlCEm
> asc assembly/index.ts --target release

[arcanis]

As for detecting which script to use during scaffolding:

• You can use $npm_config_user_agent, which contains a string that you can use to identify the package manager,

• Or you can check which lockfile exists near to the package.json you intend to modify, or one of its ancestors (for workspace support, when the lockfile is higher in the filesystem hierarchy).