Closed n4bb12 closed 4 years ago
Nice move :) ... could you share a quick guide?
@juanpicado I'm still figuring it out but here's what I got so far:
npm install -g yarn
to update the global yarn version to latest v1yarn set version berry
to enable v2 https://yarnpkg.com/getting-started/installyarn
to re-install the repo.yarn
(if using zero-install)yarn dlx @yarnpkg/pnpify --sdk vscode
to add VSCode support, (install and commit all of them if using zero-install and you want contributors to not need to do this themselves) https://yarnpkg.com/advanced/editor-sdksyarn plugin import interactive-tools
if you want the upgrade-interactive comand https://yarnpkg.com/cli/upgrade-interactive/#gatsby-focus-wrapper.npmrc
, you'll need to replicate those into the new config format since v2 no longer reads the npm configNow you have a working yarn v2 setup but your repository might still be very much incompatible. Some things you'll need to change:
node_modules
folder and no .bin
folder. Anything that relied on these needs to be changed to run through yarn instead.node
that are not inside a yarn script with yarn node
All of this is and more is documented in the migration guide https://yarnpkg.com/advanced/migration
There might be more, e.g. you'll need to change the yarn cache config for CI if you were caching node_modules. It might not work with webpack 4, in which case you'll need a bridge plugin. You might need the node-modules plugin as a last resort https://yarnpkg.com/advanced/migration#if-required-enable-the-node-modules-plugin
Hope that helps! π
This pull request introduces 27 alerts when merging 1735fa4fc7a2b7cc6449c3e500c7caa11a0447f1 into 33302dc628f76819d6b6c9b506c493643782c22c - view on LGTM.com
new alerts:
This pull request introduces 27 alerts when merging d537001e3e962bf920ad7452680ff6f8b0eee1c9 into 33302dc628f76819d6b6c9b506c493643782c22c - view on LGTM.com
new alerts:
This pull request introduces 27 alerts when merging 87a09c594a93f487dfd0fac2807e654bb0989f89 into 33302dc628f76819d6b6c9b506c493643782c22c - view on LGTM.com
new alerts:
Keeping this for future reference, I'll not migrate this project for now and work on https://github.com/n4bb12/verdaccio-auth or verdaccio 5 instead.
@n4bb12 do you have some feedback to share? what were the main blockers? In any case, I took the liberty of integrating your comment https://github.com/n4bb12/verdaccio-github-oauth-ui/pull/53#issuecomment-671027621 with a few minor tweaks into our migration guide (here) - thanks for doing this, it's really useful as it's often difficult for us to get the right perspective!
@arcanis wow how did you find this π΅
I didn't give up on v2 by closing this, I just thought that it might not be worth doing it in this repo because I'm moving efforts to a successor.
The docs helped me get my head around the concept and configuring everything, but I'm still struggling.
Some things I hit my foot against:
A) parcel had this error building with yarn2. I ended up switching to microbundle to work around it.
B) Randomly I got "EISDIR: illegal operation on a directory, read" when trying to install a new package (don't remember which). It went away by deleting the local .yarn/cache and re-installing. Gladly only had this once.
C) I got this by just expanding the .yarn/cache folder in VSCode. Locked files are a common issue with VSCode on Windows for some tools, but I don't remember yarn1 having this problem with node_modules and VSCode. Usually I resolve VSCode locking issues by putting things on search and watch exclude, but this was already the case for .yarn, so I'm trying not to open that folder and mostly I don't need to, so it's not a biggie.
C) I'm trying to start up verdaccio with my locally built plugin. Previously I was able to do it in various ways, e.g. by copying it into node_modules or loading it from a plugins directory that verdaccio can be configured to load from. With v2 any dependencies used by the built plugin are not found by any of these mechanisms. Verdaccio require
's plugins, so I just need to find a way to make built plugins visible to yarn's module resolution AND also having it resolve the module's dependencies. My next attempt will be to pack the built plugin and copy it into the yarn cache folder. I couldn't find anything useful on GitHub or in the docs but it's also probably not a mainstream issue.
Thanks for going through the hurdles required to move something like yarn berry forward. π»
A) parcel had this error building with yarn2. I ended up switching to microbundle to work around it.
They've fixed these issues / added PnP compatibility in V2 (parcel@next)
B) Randomly I got "EISDIR: illegal operation on a directory, read" when trying to install a new package (don't remember which). It went away by deleting the local .yarn/cache and re-installing. Gladly only had this once.
We've seen this issue before but been unable to reproduce, thanks to those logs in point C I was able to figure out why it was happening. Turns out we already fixed it in https://github.com/yarnpkg/berry/pull/1674 which hasn't been released yet, but now we know why it was happening so thank you! :+1:
C) I got this by just expanding the .yarn/cache folder in VSCode. Locked files are a common issue with VSCode on Windows for some tools, but I don't remember yarn1 having this problem with node_modules and VSCode. Usually I resolve VSCode locking issues by putting things on search and watch exclude, but this was already the case for .yarn, so I'm trying not to open that folder and mostly I don't need to, so it's not a biggie.
This was improved / fixed in https://github.com/yarnpkg/berry/pull/1593, also not released yet.
The correct error is actually EPERM: operation not permitted, copyfile
but before the bugfix in https://github.com/yarnpkg/berry/pull/1674 it was EPERM: operation not permitted, mkdir
C) I'm trying to start up verdaccio with my locally built plugin. Previously I was able to do it in various ways, e.g. by copying it into node_modules or loading it from a plugins directory that verdaccio can be configured to load from. With v2 any dependencies used by the built plugin are not found by any of these mechanisms. Verdaccio require's plugins, so I just need to find a way to make built plugins visible to yarn's module resolution AND also having it resolve the module's dependencies. My next attempt will be to pack the built plugin and copy it into the yarn cache folder. I couldn't find anything useful on GitHub or in the docs but it's also probably not a mainstream issue.
If I understand this correctly i'll point you to this section in the docs
Tip: Yarn 2 implements support for self-references, making the link: protocol unneeded in most cases. Any file that's part of a package will always be able to import any file from its own package using the package name - even the top-level project! Just add a "name": "app" field into your top-level package.json, and you'll be able to use import 'app/Toolbar' without further ado. https://yarnpkg.com/features/protocols/#why-is-the-link-protocol-recommended-over-aliases-for-path-mapping
@merceyz thanks for the info and for processing all this π
The link protocol brought me a step further. (I used it in devDependencies since it's only for local testing and shouldn't be published.)
"verdaccio-auth": "link:./plugins/verdaccio-auth"
Unfortunately I'm now here
(node:1072) [MODULE_NOT_FOUND] Error: verdaccio tried to access verdaccio-auth, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
I set pnpMode: loose
but it didn't do the trick.
What would be the intended way to load arbitrary plugins when plugins by their nature are not declared as dependencies?
Unfortunately I'm now here (node:1072) [MODULE_NOT_FOUND] Error: verdaccio tried to access verdaccio-auth, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound. I set pnpMode: loose but it didn't do the trick.
This is actually just a warning, though you're only supposed to see it in pnpMode: loose
, this has been fixed in master.
You can test with master using
yarn set version from sources
What would be the intended way to load arbitrary plugins when plugins by their nature are not declared as dependencies?
Loading them on behalf of the config that declares it using createRequire. This isn't PnP specific though, everything should do this to not rely on hoisting. Could you provide a reproduction for this so that I can fix it in verdaccio?
@merceyz I think this would be the essence of how verdaccio loads plugins. Dependencies are checked in, so you only need to checkout the yarn1/yarn2 branches and run node app
:
https://github.com/n4bb12/minimal-plugin-example/tree/yarn1
$ node app
hello world
https://github.com/n4bb12/minimal-plugin-example/tree/yarn2
$ node app
internal/modules/cjs/loader.js:1083
throw err;
^
Error: Cannot find module 'lodash.lowercase'
Require stack:
- D:\Projects\n4bb12\minimal-plugin-example\plugins\foo\foo.js
- D:\Projects\n4bb12\minimal-plugin-example\app\index.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:1080:15)
at Function.Module._load (internal/modules/cjs/loader.js:923:27)
at Module.require (internal/modules/cjs/loader.js:1140:19)
at require (internal/modules/cjs/helpers.js:75:18)
at Object.<anonymous> (D:\Projects\n4bb12\minimal-plugin-example\plugins\foo\foo.js:1:19)
at Module._compile (internal/modules/cjs/loader.js:1251:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1272:10)
at Module.load (internal/modules/cjs/loader.js:1100:32)
at Function.Module._load (internal/modules/cjs/loader.js:962:14)
at Module.require (internal/modules/cjs/loader.js:1140:19) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'D:\\Projects\\n4bb12\\minimal-plugin-example\\plugins\\foo\\foo.js',
'D:\\Projects\\n4bb12\\minimal-plugin-example\\app\\index.js'
]
}
With yarn1 the following is possible:
You can find the corresponding verdaccio code here: https://github.com/verdaccio/verdaccio/blob/master/src/lib/plugin-loader.ts#L14
Codecov Report
0.00% <0.00%> (ΓΈ)
0.00% <0.00%> (ΓΈ)
Continue to review full report at Codecov.