yarn.lock should be ignored

[cemremengu]

No description provided.

[cemremengu]

.nvmrc too I think

[aboutlo]

@cemremengu Should I then ignore as well those file too?

• yarn.lock
• .editorconfig
• .gitignore
• .npmignore
• .nvmrc
• .prettierrc
• .travis.yml

[cemremengu]

The listings in .gitignore file should be enough (npm will also use it so no need for an .npmignore file) just add .nvmrc and .yarn.lock to it. Also you should delete the files from the repo as well

[aboutlo]

🤔I see, I guess I misunderstood your suggestion. Let me clarify
.nvmrc is useful to keep in the repo in order to enforce the default node version if someone is working on it.
yarn.lock is required in the repo for dev dependencies
So, to me, the best way it's adding both of them in the .npmignore. TBH Not sure it worth to avoid this two files being published

[cemremengu]

I think .nvmrc and .lock files are more suitable for applications rather than libraries. When making the suggestion my motivation was actually to have a similar structure as other plugins in the organization for consistency however the decision is yours to make :)

[aboutlo]

@mcollina I saw you have approved my PR but after the chat with @cemremengu I'm not sure it's anymore aligned. Maybe you have a different perspective on this one

[mcollina]

Either it's fine. It depends on what you prefer to do. We gitignore yarn.lock and package-lock.json in all of the other repos of this orgs. Mainly because it complicates maintenance over time, and it prevent certain problems for being exposes. lock files are great for apps, not so much for modules and libraries.

[aboutlo]

Does it mean you prefer to fail if your dependencies has been changed? So that you can fix the issue.
Howver, here we have zero dependencies apart the dev dependencies. To me it's nice to keep jest, jsdoc-markdown locked but defenitely not strong opinion here. I understand consistency so no problem to move both of them to .gitignore if you prefer so.

[mcollina]

Yes, I prefer things to fail for modules. Otherwise you may not see that your module is broken when installed, due to an updated dependency.

(this is more philosophical in fact, this module has no dependencies - kind of the reason why I didn’t say anything in the beginning)

[aboutlo]

fixed by 8ea582f