New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
project initialization has dependency on yarn "classic" #3478
Comments
A work-around is available:
It is the initial bootstrapping of the new project which has this dependency on yarn "classic" being installed. |
You can run this:
Or maybe all uppercase |
Thanks @mrgrain . I will try that. I would have tried it last night if that option were listed in the |
You get the full help per project type with this:
But it's not very obvious right now that you can do that. |
Well ... that gets further ... but still no joy. Here's what that attempt shows me:
Note that |
Thanks for testing this out. This is indeed a new error now. Seems like the eslint binary cannot be found and/or for some reason the commands |
This line should have made sure of it but doesn't seem to work: |
Okay it seems like we never changed the default linker in |
So, a bit more testing. Good news - I was able to get it working with a carefully set environment variable. Bad news - it looks like the default path creates a A path that works:
I tried initializing a And the bad news - after finishing up the initialization, the resulting
which I didn't think was valid YAML syntax. That said - Adding the following to my
I hope this helps identify what fixes to make. |
One more note - For example:
also works (with |
FWIW, this is valid YAML because any JSON is valid YAML.
|
Thanks @mrgrain - until today I didn't know that. |
Moving forward, I think we need to change the default setting for the linker. @blimmer what do you think ? |
Fundamentally I think projen's concept of providing an |
Or I suppose we could state that |
How about just using This would also serve to self-document working in the same "style" as the package manager/tool-chain choice either made or presumed by the user. |
The problem with this approach is that every Component now has to be aware of the package manager used and has to actively support it. For example the project.addTask('esbuild', 'esbuild --fix'); That's nice and simple and portable. If the component needs to wrap the command with assert(project instanceof NodeProject); // a bit constructed, but now this component cannot work with other projects anymore
switch(project.packageManager) {
case NodePackageManager.YARN_BERRY:
case NodePackageManager.YARN_CLASSIC:
project.addTask('esbuild', 'yarn exec esbuild --fix');
break;
case NodePackageManager.PNPM:
project.addTask('esbuild', 'pnpm exec esbuild --fix');
break;
case NodePackageManager.NPM:
default:
project.addTask('esbuild', 'npx esbuild --fix');
break;
} and every component would have to do this! My proposal is essentially that the "wrapping" is done once by the task runtime. |
I'm going to speak from the perspective of what we'd do in a perfect world, noting that this might be difficult or a large-ish overhaul of the code. The current behavior of always using Instead of offloading the We could even eventually deprecate In the meantime, though, I don't see a huge issue with forcing the |
When creating a new projen project, the default packageManager for the NodeProject (and sub-classes) is set to
NodePackageManager.YARN_CLASSIC
which represents yarn "classic".This results in a run of
yarn install --check-files
during the initialization of the project. This, because of the command-line invocation parameters, implies a subtle dependency on yarn "classic" being the version ofyarn
which is in-effect whennpx projen new
is run.To re-create the problem, install yarn "modern" (use
corepack enable
and then runyarn set version stable
in a folder above where the new project will reside). Create the folder for the new project, change directory to that folder, and runnpx projen new typescript
. An initialnpm install
will be performed and then the.projenrc.ts
file will be generated and synthesized. At this point, aninstall
task is run for the new project. This is where a second install is performed and, because the defaultpackageManager
is set to use yarn "classic", the install command run isyarn install --check-files
. When the version ofyarn
that is configured is not yarn "classic", this install fails and thenpx projen new typescript
initialization steps fails.The text was updated successfully, but these errors were encountered: