Skip to content
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

add file exists check to prevent override of existing .gitignore file… #1630

Merged
merged 3 commits into from Jul 8, 2022

Conversation

maxgaurav
Copy link
Contributor

@maxgaurav maxgaurav commented Apr 29, 2022

… within collection

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

[ X ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

When attempting to create new application through nest cli when collection is provided which contains a gitignore file either fails with git repository init failure or existing gitignore file being overridden by default nestjs template content.
Issue Number: #1630

What is the new behavior?

The create git ignore file will skip creation if the file already exists

Does this PR introduce a breaking change?

[ ] Yes
[ X ] No

Other information

Comment on lines 206 to 211
return fileExists(filePath).then(exists => {
if (!exists) {
return promisify(fs.writeFile)(filePath, fileContent);
}
return;
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not use async/await here

Suggested change
return fileExists(filePath).then(exists => {
if (!exists) {
return promisify(fs.writeFile)(filePath, fileContent);
}
return;
});
const gitIgnoreFileExists = await fileExists(filePath);
if (!gitIgnoreFileExists) return promisify(fs.writeFile)(filePath, fileContent);

@@ -203,7 +203,12 @@ const initializeGitRepository = async (dir: string) => {
const createGitIgnoreFile = (dir: string, content?: string) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const createGitIgnoreFile = (dir: string, content?: string) => {
const createGitIgnoreFile = async (dir: string, content?: string) => {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi sorry for the dealy in response. Got stuck in my main project. I have no problem doing it this way, I was just trying to get the flow what was already there. If needed I can change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe async/await will be better to follow

@kamilmysliwiec
Copy link
Member

🏓

Comment on lines 258 to 259
const fileExists = (path: string) => {
return promisify(fs.access)(path).then(() => true).catch((err: any) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, I don't see any reason to use promises here because all the other tasks will need to wait the createGitIgnoreFile one

So can you replace fs.access by fs.accessSync?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just changed the flow to use the synchronous access and mainly reverted the createGitIgnoreFile to be mostly the same code except adding the check to file exist then it returns.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you run npm ci && npm run format to fix formatting issues?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but only commit the actions/new.action.ts xD

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, let me help you with that. I just ran that command myself

@@ -250,4 +254,17 @@ export const retrieveCols = () => {
}
};

const fileExists = (path: string) => {
try{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
try{
try {


throw err;
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a separate note, this whole gitignore problem is there as the npm does not copy .gitignore files to the distributions. Since we are using angular schematics which allows template prefix/suffix to be added which can be automatically removed through the schematics build process. I have achieved the same for my collection
Reference: https://github.com/maxgaurav/nestjs-template-schematics

Would it be okay that do the same for the nestjs schematics as well by opening a PR which can allow managing of .gitignore file through schematics.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure! I'll close the PR #1649 then

Which means that we can close this PR as well, right? then after your fix on that schematics issue, we could open another one to drop the workaround implemented on this repo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, makes sense. But form then the responsibility of having .gitingore file will be to the schematics, if not provided then gitingore will not be there in the project structure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once I complete the functionality I will map the pull request here for refernce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants