-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Fix setup issues on Windows, and update README with Windows-specific steps where required. #320
Conversation
README.md
Outdated
@@ -39,19 +39,37 @@ aws s3 cp <s3-url> ~/aws-cdk.zip | |||
|
|||
Once you've downloaded the bits, install them into `~/.cdk`: | |||
|
|||
#### Linux/MacOS (Shell) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer having one block for *NIX instructions, and one block for Windows instructions. Interweaving them *NIX - Windows - *NIX - Windows... Seems not convenient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I agree. When we move these to our docs, we can just use tabs, and this also makes sure the steps are consistent between the platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that not effectively separate them out as well? You better not make me click the "Windows" tab on every new section!
I'm with Romain. Think of the user experience, and how you would feel when presented with fragments of instructions that you would have to piece together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Rico and Romain, the installation instructions for Win and *NIX should be in separate blocks of text with a clear title indicating which OS the instructions are for. They should not be interwoven together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tab selection is "sticky" for all sections/topics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
@@ -7,7 +7,7 @@ | |||
"%name%": "bin/%name%.js" | |||
}, | |||
"scripts": { | |||
"prepare": "tsc && chmod a+x bin/%name%.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be "build" now, in fact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even in the init templates? prepare
is a well-known script name, but build
isn't (https://docs.npmjs.com/misc/scripts).
Holding off on changing to build
this iteration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, build
is the idiomatic way. We've been abusing prepare
(my fault).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
child_process.spawn('tsc') | ||
|
||
if (os.platform() !== 'win32') { | ||
child_process.spawn('chmod', [ 'a+x', 'bin/%name%.js' ]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't be turned into the actual name unless you name the file prepare.template.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wontfix
(prepare.js
has been removed)
packages/aws-cdk/lib/init.ts
Outdated
@@ -201,7 +201,10 @@ async function postInstall(language: string) { | |||
} | |||
|
|||
async function postInstallTypescript() { | |||
const yNpm = path.join(CDK_HOME, 'bin', 'y-npm'); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the blank line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To keep you code reviewers on your toes! >_>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
packages/aws-cdk/lib/init.ts
Outdated
const yNpm = path.join(CDK_HOME, 'bin', 'y-npm'); | ||
|
||
const yNpm = os.platform() === 'win32' ? | ||
path.join(CDK_HOME, 'node_modules', '.bin', 'y-npm.cmd') : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the .cmd
extension necessary when you pass shell: true
to spawn
? It seems not needed when spawn
ing npm
, so I'm slightly confused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also fairly sure it's not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.cmd
isn't necessary for spawn
, but it is necessary for fs.pathExists(yNpm)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wontfix
README.md
Outdated
@@ -39,19 +39,37 @@ aws s3 cp <s3-url> ~/aws-cdk.zip | |||
|
|||
Once you've downloaded the bits, install them into `~/.cdk`: | |||
|
|||
#### Linux/MacOS (Shell) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I agree. When we move these to our docs, we can just use tabs, and this also makes sure the steps are consistent between the platforms.
tools/y-npm/bin/.y-npm.cmd
Outdated
@@ -0,0 +1,7 @@ | |||
@IF EXIST "%~dp0\node.exe" ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is does this file name start with a "."?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to avoid any confusion between %~dp0\..\y-npm\bin\y-npm
and %~dp0\..\y-npm\bin\.y-npm.cmd
.
I will rename from .y-npm.cmd
to y-npm.template.cmd
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
tools/y-npm/bin/.y-npm.cmd
Outdated
@@ -0,0 +1,7 @@ | |||
@IF EXIST "%~dp0\node.exe" ( | |||
"%~dp0\node.exe" "%~dp0\..\y-npm\bin\y-npm" %* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two spaces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya got me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
tools/y-npm/lib/run-npm-command.ts
Outdated
@@ -80,7 +80,7 @@ export function runCommand(command: string, args: string[], additionalEnv?: Node | |||
env[key] = value; | |||
} | |||
} | |||
const child = spawn(command, args, { detached: false, env, stdio: ['inherit', 'pipe', 'pipe'] }); | |||
const child = spawn(command, args, { detached: false, env, shell: true, stdio: ['inherit', 'pipe', 'pipe'] }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a comment explaining why shell: true
is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
@@ -7,7 +7,7 @@ | |||
"%name%": "bin/%name%.js" | |||
}, | |||
"scripts": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is messy.
I rather we do this:
Instead of bin/xxx.ts
, let's go back to using lib/index.ts
as the entrypoint of apps and have cdk.json
run node lib/index.js
. Much simpler, cross platform and less messy. This will make it also easier to migrate to #216.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surely the place where the entry-point file lives (bin/
vs lib/
) has no bearing on how it's executed? I vote we still put the entry point in bin/main.ts
so it's very clear and easy to find, and everything in lib/
can automatically be assumed to be application-specific constructs.
Then, we can still decide on how we want to execute it, which can still be through node bin/main.js
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. Let's just not make it executable then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
Removed chmod
invocation, and remove prepare.js
as it is no longer needed without the chmod
invocation.
README.md
Outdated
Once you've downloaded the bits, install them into `~/.cdk`: | ||
Once you've downloaded the bits, install them into `~/.cdk` and make sure that `~/.cdk/bin` is in your `PATH`: | ||
|
||
#### Linux/MacOS (Shell) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change "Shell" to "bash/zsh"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do. I couldn't find a profile that is read by all interactive shells (.profile
is only read by login shells). If I missed one let me know--writing to a single profile would be better than writing to profiles for all common shells.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
|
||
# Add ~/.cdk/bin to your PATH | ||
$profilePath = Join-Path ([Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments)) "Profile.ps1" | ||
Add-Content -Path $profilePath -Value '$env:Path = "$env:Path;$env:UserProfile\.cdk\bin"' | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be an H2 (##
) here which separates "Install to ~/.cdk" section and the next section which is "Install the command-line toolkit and docs"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
|
||
# Add ~/.cdk/bin to your PATH | ||
$profilePath = Join-Path ([Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments)) "Profile.ps1" | ||
Add-Content -Path $profilePath -Value '$env:Path = "$env:Path;$env:UserProfile\.cdk\bin"' | ||
``` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be an H3 (###
) here to separate the "Install to ~/.cdk" section and the next section which is "Install the command-line toolkit and docs".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see two PR comments (one suggesting H2
, the other suggesting H3
). I will add an H3
header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
H3 is correct I believe
@RomainMuller any more comments? Can you approve the change? |
@@ -201,7 +201,9 @@ async function postInstall(language: string) { | |||
} | |||
|
|||
async function postInstallTypescript() { | |||
const yNpm = path.join(CDK_HOME, 'bin', 'y-npm'); | |||
const yNpm = os.platform() === 'win32' ? | |||
path.join(CDK_HOME, 'node_modules', '.bin', 'y-npm.cmd') : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle, ${CDK_HOME}/bin
is a symlink to node_modules/.bin
, so I'm not sure the distinction is 100% useful here. It doesn't hurt though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the Windows doesn't understand the symlink, so we have to give it a symlink-less path.
By submitting this pull request, I confirm that my contribution is made under
the terms of the beta license.